Re: [VOTE] Release Apache Log4net 3.0.1

[Davyd McColl]

+1

- tests all pass

- sigs look fine


-d

On 2024-09-24 21:48, Jan Friedrich wrote:

This is a vote to release the Apache Log4net 3.0.1.

Website: https://logging.staged.apache.org/log4net/release/release-notes.html
GitHub: https://github.com/apache/logging-log4net
GitHub release (pre-release): 
https://github.com/apache/logging-log4net/releases/tag/rc/3.0.1-rc1
Commit: 8bf4313cdc7dc2bcc14583c8b206c5a25b7edf4a
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4net
Signing key: 0x7D24496A230E29D6349A99EF583E491578F02D5D

Please download, test, and cast your votes on this mailing list.

How to run the unit tests?
- install docker (if you haven't already)
   - https://docs.docker.com/engine/install/
- in logging/log4net run
   - `docker build -t log4net-builder .`
   - `docker run -it log4net-builder`
 - this will
   - install all dependencies in the container
   - build src/log4net.sln
   - inside the container run
 - `dotnet test /logging-log4net/src/log4net.sln`

[ ] +1, release the artifacts
[ ] -1, don't release, because ...

This vote is open for 72 hours and will pass unless getting a
net negative vote count. All votes are welcome and we encourage
everyone to test the release, but only the Logging Services PMC
votes are officially counted.

Re: [VOTE] Release Apache Log4net 3.0.0

[Davyd McColl]

Hi

Apologies for the late response. FWIW, my +1 too.

-d


On 15 September 2024 20:59:13 Jan Friedrich  wrote:


Hi,

and here is my +1.

With that the vote passed with 3 +1 votes from Piotr P. Karwasz, Volkan 
Yazıcı and myself.

I will continue the release process.

Jan

Friday, September 13, 2024, 9:17:46 AM, you wrote:


+1



✅ Signatures
✅ Checksums
✅ Build (using Docker)
✅ Tests (using Docker)



Congratulations to the Log4net crew (in particular, to Jan and Davyd 🙇)
for their 3rd major release! 🎉 Keep up the great work! 💯





On Thu, Sep 12, 2024 at 8:54 PM Jan Friedrich  wrote:



This is a vote to release the Apache Log4net 3.0.0.

Website:
https://logging.staged.apache.org/log4net/release/release-notes.html
GitHub: https://github.com/apache/logging-log4net
GitHub release (pre-release):
https://github.com/apache/logging-log4net/releases/tag/rc/3.0.0-rc1
Commit: 42ba791745ceb7ff922d828c6c5572ed918df84b
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4net
Signing key: 0x7D24496A230E29D6349A99EF583E491578F02D5D


Please download, test, and cast your votes on this mailing list.

How to run the unit tests?
- install docker (if you haven't already)
  - https://docs.docker.com/engine/install/
- in logging/log4net run
  - `docker build -t log4net-builder .`
  - `docker run -it log4net-builder`
- this will
  - install all dependencies in the container
  - build src/log4net.sln
  - inside the container run
- `dotnet test /logging-log4net/src/log4net.sln`

[ ] +1, release the artifacts
[ ] -1, don't release, because ...

This vote is open for 72 hours and will pass unless getting a
net negative vote count. All votes are welcome and we encourage
everyone to test the release, but only the Logging Services PMC
votes are officially counted.

Re: [log4net] INFRA-managed NuGet account

[Davyd McColl]

I've accepted; delete the other org at your convenience.


-d

On 2024-09-02 11:39, Volkan Yazıcı wrote:
I have succeeded in convincing INFRA to create a NuGet organization 
(INFRA-25617)  that 
we can move our .NET projects to. As a result, INFRA has created the 
`asf` NuGet organization and added existing members of the 
`Apache.Logging` organization to there.


*Jan, Davyd, Dominik, you should have received an invitation to join 
the `asf` NuGet organization. Could you accept it and respond to this 
mail, please?* Consequently, I will remove the `Apache.Logging` 
organization and make necessary website changes.


For those interested, this change doesn't affect the Log4Net NuGet 
package coordinates. Hence, no visible change from users' point of 
view. See INFRA-25617 for the rationale and other details.

[RESULT] [VOTE] Release Apache Log4Net 2.0.17

[Davyd McColl]

Hi all


With +3 binding votes (Christian, Volkan and myself), apache log4net 
2.0.17 is released and available:


https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.17


Source snapshot at: 
https://downloads.apache.org/logging/log4net/source/apache-log4net-source-2.0.17.zip



Thanks

-d


On 2024/03/19 10:44, Christian Grobmeier wrote:

+1

Checked only formalities since I don't have an idea about .NET, but so far, 
looks good!


On Sat, Mar 16, 2024, at 11:07, Volkan Yazıcı wrote:

+1

Checked sigs, hashes, `LICENSE` files, and release notes.



On Fri, Mar 15, 2024 at 1:29 PM Davyd McColl  wrote:

Hi all,

This is a vote to release the Apache Log4net 2.0.17.

Website:
https://logging.staged.apache.org/log4net/release/release-notes.html
GitHub: https://github.com/apache/logging-log4net
GitHub release (pre-release):
https://github.com/apache/logging-log4net/releases/tag/rel/2.0.17-rc1
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4net

Please download, test, and cast your votes on this mailing list.

[ ] +1, release the artifacts
[ ] -1, don't release, because...

This vote is open for 72 hours and will pass unless getting a
net negative vote count. All votes are welcome and we encourage
everyone to test the release, but only the Logging Services PMC
votes are officially counted.


Thanks to Jan for basically doing all of this (:

-d

Re: [VOTE] Release Apache Log4Net 2.0.17

[Davyd McColl]

Hi

Yes, everything should be done via npm scripts. So I should remove any 
confusing .cmd files.


As for the version, I should update that, but it's minor. That version 
comes from package.json and will only show when running npm commands. But I 
admit it's confusing.


-d


On 15 March 2024 16:28:47 "Gary D. Gregory"  wrote:


We might need better build instructions... for me at least ;-)

I take it the build.cmd file should be removed since it's not mentioned in 
https://github.com/apache/logging-log4net/blob/master/doc/BUILDING.md ?


BUILDING.md  contains a section called "TL;DR (!Windows):" which is too 
easy to confuse with "TL;DR (Windows):", just say "TL;DR (non-Windows):", 
there is no need to be clever here IMO.


When I say "npm i" and then "npm run build", it starts with:


log4net@2.0.12 prebuild
run-s clean-build
log4net@2.0.12 clean-build
rimraf build
log4net@2.0.12 build
zarro @


Why does it say log4net@2.0.12 when I am building 2.0.17?

Then the build errors out with https://paste.apache.org/1ropz

I, off course, don't know what I'm doing with .net... ;-)

Gary


On 2024/03/15 12:28:03 Davyd McColl wrote:

Hi all,

This is a vote to release the Apache Log4net 2.0.17.

Website:
https://logging.staged.apache.org/log4net/release/release-notes.html
GitHub: https://github.com/apache/logging-log4net
GitHub release (pre-release):
https://github.com/apache/logging-log4net/releases/tag/rel/2.0.17-rc1
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4net

Please download, test, and cast your votes on this mailing list.

[ ] +1, release the artifacts
[ ] -1, don't release, because...

This vote is open for 72 hours and will pass unless getting a
net negative vote count. All votes are welcome and we encourage
everyone to test the release, but only the Logging Services PMC
votes are officially counted.


Thanks to Jan for basically doing all of this (:

-d

[VOTE] Release Apache Log4Net 2.0.17

[Davyd McColl]

Hi all,

This is a vote to release the Apache Log4net 2.0.17.

Website: 
https://logging.staged.apache.org/log4net/release/release-notes.html

GitHub: https://github.com/apache/logging-log4net
GitHub release (pre-release): 
https://github.com/apache/logging-log4net/releases/tag/rel/2.0.17-rc1

Distribution: https://dist.apache.org/repos/dist/dev/logging/log4net

Please download, test, and cast your votes on this mailing list.

[ ] +1, release the artifacts
[ ] -1, don't release, because...

This vote is open for 72 hours and will pass unless getting a
net negative vote count. All votes are welcome and we encourage
everyone to test the release, but only the Logging Services PMC
votes are officially counted.


Thanks to Jan for basically doing all of this (:

-d

Re: [VOTE] Release Apache Log4net 2.0.16

[Davyd McColl]

Hi Gary

I receive on the order of a hundred or more emails every day. Searches fail 
me, at least in Thunderbird. I will rather just keep a record as they come 
in, but thanks for the suggestion.


-d


On 08 March 2024 17:09:13 Gary Gregory  wrote:


You don't need memory, if you deleted the messages already from your email
app, go to lists.apache.org

Gary


On Fri, Mar 8, 2024, 8:59 AM Davyd McColl  wrote:


Hi Gary


I'll try to remember that for the future. From memory now, there was
only one person who had any holdups and that was due to outdated build
docs from me - so it should be resolved. There were no -1's, and at
least 4 +1's that I saw. I'll try to keep better tally next time.


-d

On 2024/03/08 14:22, Gary Gregory wrote:
> Process:
>
> You need to reply to this thread with a [RESULT] prefix, tally all the
> votes, and say whether the vote passes or not. It is helpful to note
which
> votes are binding or not.
>
> Gary
>
> On Fri, Mar 8, 2024, 6:06 AM Davyd McColl  wrote:
>
>> Hi all
>>
>>
>> Thanks for all the checking - log4net 2.0.16 is out in the wild now (:
>>
>>
>> -d
>>
>> On 2024/03/08 00:02, Jan Friedrich wrote:
>>> Hello Gary,
>>>
>>> the errors are in the examples project for .net compact framework
(which
>> is no longer supported by microsoft):
>>>
>>
C:\Users\ggregory\rc\apache-log4net-source-2.0.16\examples\netcf\1.0\Tutorials\ConsoleApp\cs\src\ConsoleApp.csdproj(23,1):
>> error MSB4075:
>>> The project file
>>
"C:\Users\ggregory\rc\apache-log4net-source-2.0.16\examples\netcf\1.0\Tutorials\ConsoleApp\cs\src\ConsoleApp.csdproj"
>> must be opened in the Visual Studio IDE and converted to the latest
version
>> before it can be built by MSBuild.
>>> -> This project file can only be opened by VS 2003.
>>>
>>> In the next release we will drop support for those exotic frameworks
and
>> delete the corresponding examples.
>>> I've already updated all the examples in my feature branch for this.
>>>
>>> Regards.
>>>
>>> Jan
>>>
>>> Thursday, March 7, 2024, 10:28:40 PM, you wrote:
>>>
>>>> I've failed to build probably because the machine I am doing this on
is
>> DNS locked down for security and can only access certain sites.
>>>> I was able to install install-dotnet-core-sdk-1.1.ps1 but not
>> install-net-framework-sdk-3.5.ps1 (Error 0x800F0954 in a dialog that
points
>> to
>>
https://learn.microsoft.com/en-US/troubleshoot/windows-client/application-management/dotnet-framework-35-installation-error
)
>> but I also don't know if how if this machine has enough already on top
of
>> Microsoft Windows [Version 10.0.19045.4046]
>>>> My results: https://paste.apache.org/jj3c8
>>>> I rebooted and tried again with the same results.
>>>> Gary
>>>> On 2024/03/07 03:11:22 Robert Middleton wrote:
>>>>> +1
>>>>> Verified the following:
>>>>> * apache-log4net-source-2.0.16.zip and associated sha/signature
>>>>> * apache-log4net-binaries-2.0.16.zip and associated sha/signature
>>>>> It looks all good to me.
>>>>> -Robert Middleton
>>>>> On Tue, Mar 5, 2024 at 1:20 AM Ralph Goers <
ralph.go...@dslextreme.com>
>> wrote:
>>>>>> +1
>>>>>> Verified signatures
>>>>>> Verified hashes
>>>>>> Verified License and Notice files.
>>>>>> Note - the copyright year should be the first year the code was
>> created. You can update it to include “-(currentYear}” but that is not
>> strictly necessary.
>>>>>> Ralph
>>>>>>> On Mar 4, 2024, at 10:48 AM, Jan Friedrich 
>> wrote:
>>>>>>> +1
>>>>>>> Unit tests on my machine were successful.
>>>>>>> We integrated the new version into our test environment and all
>> manual tests were successful.
>>>>>>> Jan
>>>>>>>> +1
>>>>>>>> Verified signatures.
>>>>>>>> Verified hashes.
>>>>>>>> `NOTICE` contains 2022 as the copyright year, but I don't find it
a
>>>>>>>> blocker. (I have fixed it in `master`.)
>>>>>>>> On Fri, Mar 1, 2024 at 2:19 PM Davyd McColl 
>> wrote:
>>>>>>>>> Hi all
>>>>>>>>> This is the vote to release Apache log4net version 2.0.16
>>>>>>>>> Website:
>>>>>>>>>
>> https://logging.staged.apache.org/log4net/release/release-notes.html
>>>>>>>>> GitHub: https://github.com/apache/logging-log4net
>>>>>>>>> GitHub release (pre-release):
>>>>>>>>>
https://github.com/apache/logging-log4net/releases/tag/2.0.16-rc1
>>>>>>>>> Distribution: I'm not sure -
>>>>>>>>> https://dist.apache.org/repos/dist/dev/logging/log4net should
have
>>>>>>>>> 2.0.16 binaries and source (I've added via SVN), but I'm not
seeing
>>>>>>>>> them. Any help appreciated.
>>>>>>>>> Please have a look at the staging site & artifacts and test (if
>> you can
>>>>>>>>> - clone, `npm i`, `npm test`)
>>>>>>>>> [ ] +1, release the artifacts
>>>>>>>>> [ ] -1, don't release, because
>>>>>>>>> (thanks Piotr: I copied most of your last VOTE mail!)
>>>>>>>>> -d

Re: [VOTE] Release Apache Log4net 2.0.16

[Davyd McColl]

Hi Gary


I'll try to remember that for the future. From memory now, there was 
only one person who had any holdups and that was due to outdated build 
docs from me - so it should be resolved. There were no -1's, and at 
least 4 +1's that I saw. I'll try to keep better tally next time.



-d

On 2024/03/08 14:22, Gary Gregory wrote:

Process:

You need to reply to this thread with a [RESULT] prefix, tally all the
votes, and say whether the vote passes or not. It is helpful to note which
votes are binding or not.

Gary

On Fri, Mar 8, 2024, 6:06 AM Davyd McColl  wrote:


Hi all


Thanks for all the checking - log4net 2.0.16 is out in the wild now (:


-d

On 2024/03/08 00:02, Jan Friedrich wrote:

Hello Gary,

the errors are in the examples project for .net compact framework (which

is no longer supported by microsoft):



C:\Users\ggregory\rc\apache-log4net-source-2.0.16\examples\netcf\1.0\Tutorials\ConsoleApp\cs\src\ConsoleApp.csdproj(23,1):
error MSB4075:

The project file

"C:\Users\ggregory\rc\apache-log4net-source-2.0.16\examples\netcf\1.0\Tutorials\ConsoleApp\cs\src\ConsoleApp.csdproj"
must be opened in the Visual Studio IDE and converted to the latest version
before it can be built by MSBuild.

-> This project file can only be opened by VS 2003.

In the next release we will drop support for those exotic frameworks and

delete the corresponding examples.

I've already updated all the examples in my feature branch for this.

Regards.

Jan

Thursday, March 7, 2024, 10:28:40 PM, you wrote:


I've failed to build probably because the machine I am doing this on is

DNS locked down for security and can only access certain sites.

I was able to install install-dotnet-core-sdk-1.1.ps1 but not

install-net-framework-sdk-3.5.ps1 (Error 0x800F0954 in a dialog that points
to
https://learn.microsoft.com/en-US/troubleshoot/windows-client/application-management/dotnet-framework-35-installation-error)
but I also don't know if how if this machine has enough already on top of
Microsoft Windows [Version 10.0.19045.4046]

My results: https://paste.apache.org/jj3c8
I rebooted and tried again with the same results.
Gary
On 2024/03/07 03:11:22 Robert Middleton wrote:

+1
Verified the following:
* apache-log4net-source-2.0.16.zip and associated sha/signature
* apache-log4net-binaries-2.0.16.zip and associated sha/signature
It looks all good to me.
-Robert Middleton
On Tue, Mar 5, 2024 at 1:20 AM Ralph Goers 

wrote:

+1
Verified signatures
Verified hashes
Verified License and Notice files.
Note - the copyright year should be the first year the code was

created. You can update it to include “-(currentYear}” but that is not
strictly necessary.

Ralph

On Mar 4, 2024, at 10:48 AM, Jan Friedrich 

wrote:

+1
Unit tests on my machine were successful.
We integrated the new version into our test environment and all

manual tests were successful.

Jan

+1
Verified signatures.
Verified hashes.
`NOTICE` contains 2022 as the copyright year, but I don't find it a
blocker. (I have fixed it in `master`.)
On Fri, Mar 1, 2024 at 2:19 PM Davyd McColl 

wrote:

Hi all
This is the vote to release Apache log4net version 2.0.16
Website:


https://logging.staged.apache.org/log4net/release/release-notes.html

GitHub: https://github.com/apache/logging-log4net
GitHub release (pre-release):
https://github.com/apache/logging-log4net/releases/tag/2.0.16-rc1
Distribution: I'm not sure -
https://dist.apache.org/repos/dist/dev/logging/log4net should have
2.0.16 binaries and source (I've added via SVN), but I'm not seeing
them. Any help appreciated.
Please have a look at the staging site & artifacts and test (if

you can

- clone, `npm i`, `npm test`)
[ ] +1, release the artifacts
[ ] -1, don't release, because
(thanks Piotr: I copied most of your last VOTE mail!)
-d

Re: [VOTE] Release Apache Log4net 2.0.16

[Davyd McColl]

Hi all


Thanks for all the checking - log4net 2.0.16 is out in the wild now (:


-d

On 2024/03/08 00:02, Jan Friedrich wrote:

Hello Gary,

the errors are in the examples project for .net compact framework (which is no 
longer supported by microsoft):

C:\Users\ggregory\rc\apache-log4net-source-2.0.16\examples\netcf\1.0\Tutorials\ConsoleApp\cs\src\ConsoleApp.csdproj(23,1):
 error MSB4075:
The project file 
"C:\Users\ggregory\rc\apache-log4net-source-2.0.16\examples\netcf\1.0\Tutorials\ConsoleApp\cs\src\ConsoleApp.csdproj"
 must be opened in the Visual Studio IDE and converted to the latest version before it 
can be built by MSBuild.

-> This project file can only be opened by VS 2003.

In the next release we will drop support for those exotic frameworks and delete 
the corresponding examples.
I've already updated all the examples in my feature branch for this.

Regards.

Jan

Thursday, March 7, 2024, 10:28:40 PM, you wrote:


I've failed to build probably because the machine I am doing this on is DNS 
locked down for security and can only access certain sites.
I was able to install install-dotnet-core-sdk-1.1.ps1 but not 
install-net-framework-sdk-3.5.ps1 (Error 0x800F0954 in a dialog that points to 
https://learn.microsoft.com/en-US/troubleshoot/windows-client/application-management/dotnet-framework-35-installation-error)
 but I also don't know if how if this machine has enough already on top of 
Microsoft Windows [Version 10.0.19045.4046]
My results: https://paste.apache.org/jj3c8
I rebooted and tried again with the same results.
Gary
On 2024/03/07 03:11:22 Robert Middleton wrote:

+1
Verified the following:
* apache-log4net-source-2.0.16.zip and associated sha/signature
* apache-log4net-binaries-2.0.16.zip and associated sha/signature
It looks all good to me.
-Robert Middleton
On Tue, Mar 5, 2024 at 1:20 AM Ralph Goers  wrote:

+1
Verified signatures
Verified hashes
Verified License and Notice files.
Note - the copyright year should be the first year the code was created. You 
can update it to include “-(currentYear}” but that is not strictly necessary.
Ralph

On Mar 4, 2024, at 10:48 AM, Jan Friedrich  wrote:
+1
Unit tests on my machine were successful.
We integrated the new version into our test environment and all manual tests 
were successful.
Jan

+1
Verified signatures.
Verified hashes.
`NOTICE` contains 2022 as the copyright year, but I don't find it a
blocker. (I have fixed it in `master`.)
On Fri, Mar 1, 2024 at 2:19 PM Davyd McColl  wrote:

Hi all
This is the vote to release Apache log4net version 2.0.16
Website:
https://logging.staged.apache.org/log4net/release/release-notes.html
GitHub: https://github.com/apache/logging-log4net
GitHub release (pre-release):
https://github.com/apache/logging-log4net/releases/tag/2.0.16-rc1
Distribution: I'm not sure -
https://dist.apache.org/repos/dist/dev/logging/log4net should have
2.0.16 binaries and source (I've added via SVN), but I'm not seeing
them. Any help appreciated.
Please have a look at the staging site & artifacts and test (if you can
- clone, `npm i`, `npm test`)
[ ] +1, release the artifacts
[ ] -1, don't release, because
(thanks Piotr: I copied most of your last VOTE mail!)
-d

Re: [VOTE] Release Apache Log4net 2.0.16

[Davyd McColl]

Thanks for trying, Gary. I need to update the docs, I think, because I 
dropped client profile framework targets with the last release (iirc) 
because of that exact problem - can't install like that any more. You 
really just need the latest dotnet ask (8) and .net from windows features 
(including the option for 3.5 which says it also brings in 2)


-d


On 07 March 2024 23:29:08 "Gary D. Gregory"  wrote:

I've failed to build probably because the machine I am doing this on is DNS 
locked down for security and can only access certain sites.


I was able to install install-dotnet-core-sdk-1.1.ps1 but not 
install-net-framework-sdk-3.5.ps1 (Error 0x800F0954 in a dialog that points 
to 
https://learn.microsoft.com/en-US/troubleshoot/windows-client/application-management/dotnet-framework-35-installation-error) 
but I also don't know if how if this machine has enough already on top of 
Microsoft Windows [Version 10.0.19045.4046]


My results: https://paste.apache.org/jj3c8

I rebooted and tried again with the same results.

Gary

On 2024/03/07 03:11:22 Robert Middleton wrote:

+1

Verified the following:
* apache-log4net-source-2.0.16.zip and associated sha/signature
* apache-log4net-binaries-2.0.16.zip and associated sha/signature

It looks all good to me.

-Robert Middleton

On Tue, Mar 5, 2024 at 1:20 AM Ralph Goers  wrote:
>
> +1
>
> Verified signatures
> Verified hashes
> Verified License and Notice files.
>
> Note - the copyright year should be the first year the code was created. 
You can update it to include “-(currentYear}” but that is not strictly 
necessary.

>
> Ralph
>
> > On Mar 4, 2024, at 10:48 AM, Jan Friedrich  wrote:
> >
> > +1
> >
> > Unit tests on my machine were successful.
> > We integrated the new version into our test environment and all manual 
tests were successful.

> >
> > Jan
> >
> >> +1
> >
> >> Verified signatures.
> >> Verified hashes.
> >
> >> `NOTICE` contains 2022 as the copyright year, but I don't find it a
> >> blocker. (I have fixed it in `master`.)
> >
> >> On Fri, Mar 1, 2024 at 2:19 PM Davyd McColl  wrote:
> >
> >>> Hi all
> >>>
> >>>
> >>> This is the vote to release Apache log4net version 2.0.16
> >>>
> >>>
> >>> Website:
> >>> https://logging.staged.apache.org/log4net/release/release-notes.html
> >>>
> >>> GitHub: https://github.com/apache/logging-log4net
> >>>
> >>> GitHub release (pre-release):
> >>> https://github.com/apache/logging-log4net/releases/tag/2.0.16-rc1
> >>>
> >>> Distribution: I'm not sure -
> >>> https://dist.apache.org/repos/dist/dev/logging/log4net should have
> >>> 2.0.16 binaries and source (I've added via SVN), but I'm not seeing
> >>> them. Any help appreciated.
> >>>
> >>>
> >>>
> >>> Please have a look at the staging site & artifacts and test (if you can
> >>> - clone, `npm i`, `npm test`)
> >>>
> >>> [ ] +1, release the artifacts
> >>>
> >>> [ ] -1, don't release, because
> >>>
> >>>
> >>> (thanks Piotr: I copied most of your last VOTE mail!)
> >>>
> >>>
> >>> -d
> >>>
> >>>
> >
>

Re: Uploading release distribution for review (Was: [VOTE] Release Apache Log4net 2.0.16)

[Davyd McColl]

Hi Jan

I think you're right. It's been so long since I've used svn as a daily 
driver - even longer since I wrote a build system in c++ that hooked into 
svn and triggered workloads on commits at the server 😅. Thanks for 
figuring it out.


-d


On 02 March 2024 18:50:14 Jan Friedrich  wrote:


Hi,

I think I got it uploaded (from my machine).

choco install svn
svn co https://dist.apache.org/repos/dist/dev/logging -N 
apache-dist-logging-dev

cd apache-dist-logging-dev
svn up log4net
svn delete .\log4net\binaries\*2.0.14.*
svn add .\log4net\binaries\*
svn add .\log4net\source\*
svn commit -m 'v2.0.16'
 
Take a look at
 
https://dist.apache.org/repos/dist/dev/logging/log4net/binaries/ 
https://dist.apache.org/repos/dist/dev/logging/log4net/source/ 

@Davyd: Maybe we missed the bold lines on Friday?
 
Regards.

Jan

Friday, March 1, 2024, 6:27:38 PM, you wrote:


Hi Volkan




Thanks for taking the time to explain (:



This is pretty-much what I did, as per step 16 
of https://github.com/apache/logging-log4net/blob/master/doc/RELEASING.md - 
unless there's a typo I've made somewhere or something like that. That's 
why I'm confused as to why I can't see the artifacts in the right place ):



No need to rush on this though - monday is fine: I very likely won't do 
anything about it until then anyway (:




-d



On 2024/03/01 18:21, Volkan Yazıcı wrote:
Davyd, assuming you have `svn` in the command line, following should > get 
the job done:

    # Checkout the `dev` distribution repository
    svn co https://dist.apache.org/repos/dist/dev/logging logging-dist-dev
    cd logging-dist-dev
    # Delete old distribution files
    svn rm log4net
    # Add the new distribution of the new release
    mkdir -p log4net/2.0.16
    cp /path/to/distribution/files log4net/2.0.16/
    svn add log4net
    # Commit changes
    svn commit -m 'Add `log4net` version `2.0.16` distribution files'
I presume you are using Windows. Getting `svn` in the Windows shell is > 
explained in this SO post. > 
<https://stackoverflow.com/questions/2341134/command-line-svn-for-windows>

Let me know if this does/doesn't help.
Good luck!
On Fri, Mar 1, 2024 at 5:02 PM Davyd McColl  wrote:
    Hi Volkan
    That was my whole point with the question on my release vote: I
    have put things in svn, bit I'm not seeing them at the url you've
    posted. I assume I've done something wrong, but I don't know what
    and need someone to help. I must admit my svn-fu is rubbish so
    perhaps I just messed up there. With the other svn repos, I use
    git svn bridge, but I don't want to do that here because that repo
    us huge and filled with binaries
    TL;DR Halp! 😅
    -d
    On 01 March 2024 15:46:24 Volkan Yazıcı  wrote:

    Davyd, I am afraid it cannot qualify an official vote if the [source]
    distribution artifacts are missing. This is the whole point of
    the ASF
    release ceremony. Binary artifacts, Website, GitHub, VCS, Nuget,
    etc. can
    be the most important mediums for you and/or the project, though
    they are
    irrelevant from an ASF point of view.



    Could you upload the source distribution to the `
    https://dist.apache.org/repos/dist/dev/logging /log4net`
    Subversion folder
    along with checksum and signature files, please?
    On Fri, Mar 1, 2024 at 2:19 PM Davyd McColl  wrote:

    Hi all



    This is the vote to release Apache log4net version 2.0.16
    Website:
    https://logging.staged.apache.org/log4net/release/release-notes.html
    GitHub: https://github.com/apache/logging-log4net
    GitHub release (pre-release):
    https://github.com/apache/logging-log4net/releases/tag/2.0.16-rc1
    Distribution: I'm not sure -
    https://dist.apache.org/repos/dist/dev/logging/log4net should have
    2.0.16 binaries and source (I've added via SVN), but I'm not seeing
    them. Any help appreciated.
    Please have a look at the staging site & artifacts and test (if
    you can
    - clone, `npm i`, `npm test`)
    [ ] +1, release the artifacts
    [ ] -1, don't release, because
    (thanks Piotr: I copied most of your last VOTE mail!)
    -d

Re: Uploading release distribution for review (Was: [VOTE] Release Apache Log4net 2.0.16)

[Davyd McColl]

Hi Volkan


Thanks for taking the time to explain (:


This is pretty-much what I did, as per step 16 of 
https://github.com/apache/logging-log4net/blob/master/doc/RELEASING.md - 
unless there's a typo I've made somewhere or something like that. That's 
why I'm confused as to why I can't see the artifacts in the right place ):



No need to rush on this though - monday is fine: I very likely won't do 
anything about it until then anyway (:



-d

On 2024/03/01 18:21, Volkan Yazıcı wrote:
Davyd, assuming you have `svn` in the command line, following should 
get the job done:


# Checkout the `dev` distribution repository
svn co https://dist.apache.org/repos/dist/dev/logging logging-dist-dev
cd logging-dist-dev

# Delete old distribution files
svn rm log4net

# Add the new distribution of the new release
mkdir -p log4net/2.0.16
cp /path/to/distribution/files log4net/2.0.16/
svn add log4net

# Commit changes
svn commit -m 'Add `log4net` version `2.0.16` distribution files'


I presume you are using Windows. Getting `svn` in the Windows shell is 
explained in this SO post. 
<https://stackoverflow.com/questions/2341134/command-line-svn-for-windows>


Let me know if this does/doesn't help.

Good luck!

On Fri, Mar 1, 2024 at 5:02 PM Davyd McColl  wrote:

Hi Volkan

That was my whole point with the question on my release vote: I
have put things in svn, bit I'm not seeing them at the url you've
posted. I assume I've done something wrong, but I don't know what
and need someone to help. I must admit my svn-fu is rubbish so
perhaps I just messed up there. With the other svn repos, I use
git svn bridge, but I don't want to do that here because that repo
us huge and filled with binaries

TL;DR Halp! 😅

-d

On 01 March 2024 15:46:24 Volkan Yazıcı  wrote:


Davyd, I am afraid it cannot qualify an official vote if the [source]
distribution artifacts are missing. This is the whole point of
the ASF
release ceremony. Binary artifacts, Website, GitHub, VCS, Nuget,
etc. can
be the most important mediums for you and/or the project, though
they are
irrelevant from an ASF point of view.

Could you upload the source distribution to the `
https://dist.apache.org/repos/dist/dev/logging /log4net`
Subversion folder
along with checksum and signature files, please?

On Fri, Mar 1, 2024 at 2:19 PM Davyd McColl  wrote:


Hi all

This is the vote to release Apache log4net version 2.0.16

Website:
https://logging.staged.apache.org/log4net/release/release-notes.html

GitHub: https://github.com/apache/logging-log4net

GitHub release (pre-release):
https://github.com/apache/logging-log4net/releases/tag/2.0.16-rc1

Distribution: I'm not sure -
https://dist.apache.org/repos/dist/dev/logging/log4net should have
2.0.16 binaries and source (I've added via SVN), but I'm not seeing
them. Any help appreciated.

Please have a look at the staging site & artifacts and test (if
you can
- clone, `npm i`, `npm test`)

[ ] +1, release the artifacts

[ ] -1, don't release, because

(thanks Piotr: I copied most of your last VOTE mail!)

-d

Re: [VOTE] Release Apache Log4net 2.0.16

[Davyd McColl]

Hi Volkan

That was my whole point with the question on my release vote: I have put 
things in svn, bit I'm not seeing them at the url you've posted. I assume 
I've done something wrong, but I don't know what and need someone to help. 
I must admit my svn-fu is rubbish so perhaps I just messed up there. With 
the other svn repos, I use git svn bridge, but I don't want to do that here 
because that repo us huge and filled with binaries


TL;DR Halp!  😅

-d


On 01 March 2024 15:46:24 Volkan Yazıcı  wrote:


Davyd, I am afraid it cannot qualify an official vote if the [source]
distribution artifacts are missing. This is the whole point of the ASF
release ceremony. Binary artifacts, Website, GitHub, VCS, Nuget, etc. can
be the most important mediums for you and/or the project, though they are
irrelevant from an ASF point of view.

Could you upload the source distribution to the `
https://dist.apache.org/repos/dist/dev/logging /log4net` Subversion folder
along with checksum and signature files, please?

On Fri, Mar 1, 2024 at 2:19 PM Davyd McColl  wrote:


Hi all


This is the vote to release Apache log4net version 2.0.16


Website:
https://logging.staged.apache.org/log4net/release/release-notes.html

GitHub: https://github.com/apache/logging-log4net

GitHub release (pre-release):
https://github.com/apache/logging-log4net/releases/tag/2.0.16-rc1

Distribution: I'm not sure -
https://dist.apache.org/repos/dist/dev/logging/log4net should have
2.0.16 binaries and source (I've added via SVN), but I'm not seeing
them. Any help appreciated.



Please have a look at the staging site & artifacts and test (if you can
- clone, `npm i`, `npm test`)

[ ] +1, release the artifacts

[ ] -1, don't release, because


(thanks Piotr: I copied most of your last VOTE mail!)


-d

[VOTE] Release Apache Log4net 2.0.16

[Davyd McColl]

Hi all


This is the vote to release Apache log4net version 2.0.16


Website: 
https://logging.staged.apache.org/log4net/release/release-notes.html


GitHub: https://github.com/apache/logging-log4net

GitHub release (pre-release): 
https://github.com/apache/logging-log4net/releases/tag/2.0.16-rc1


Distribution: I'm not sure - 
https://dist.apache.org/repos/dist/dev/logging/log4net should have 
2.0.16 binaries and source (I've added via SVN), but I'm not seeing 
them. Any help appreciated.




Please have a look at the staging site & artifacts and test (if you can 
- clone, `npm i`, `npm test`)


[ ] +1, release the artifacts

[ ] -1, don't release, because


(thanks Piotr: I copied most of your last VOTE mail!)


-d

Re: [log4net] Next release

[Davyd McColl]

Hi Piotr

I actually don't know with 100% accuracy, but I did find this: 
https://www.mitchelsellers.com/blog/article/net-5-deterministic-builds-source-linking 
which is a little old but might be worthwhile investigating.


-d


On 29 February 2024 13:54:47 "Piotr P. Karwasz"  
wrote:



Hi Davyd,

On Thu, 29 Feb 2024 at 12:29, Davyd McColl  wrote:

Jan, Volkan brings up one of the sticky points - signing the release -
which I can do from my personal

machine, with the binary artifacts in place - so I could do steps 3 and
4 (build and sign) - but I'll only


This is just a curiosity (don't feel pressured to answer). Are .NET
artifacts reproducible? If it is so, could we build it and sign it in
Github actions and you could just verify that the SHAs are identical
to those locally built?

Piotr

Re: [log4net] Next release

[Davyd McColl]

Hi Volkan


If Jan feels up to the task, it would be worthwhile to give it a go. If 
nothing else, it's a bit of a "trial by fire"


of following the RELEASING.md steps to get to a release. I'm sure there 
are bits I've missed because they


seemed obvious to me or I just missed them - having a second set of eyes 
on it, going through it, has benefits


in itself. As for the actual release, I believe Jan is more than 
capable, but I understand he may be blocked


somewhere, so if I can help, I will (: It would also be a good trial run 
to find out what, if anything, is still


required to be set up for Jan (eg svn access for the docs, etc)


Jan, Volkan brings up one of the sticky points - signing the release - 
which I can do from my personal


machine, with the binary artifacts in place - so I could do steps 3 and 
4 (build and sign) - but I'll only


really have time on Friday afternoon, so I'll check it out then. In the 
mean-time, if you'd like to see


how far you can get with the RELEASING.md instructions, I'd _really_ 
appreciate it. I haven't done


a log4net release in ages because it takes a reasonable amount of time 
and motivation - substances


I'm in short supply of (when I have the motivation, I don't have the 
time, and when I have the time,


it's after a long day, and I don't have the motivation any more ): )


-d


On 2024/02/29 13:02, Volkan Yazıcı wrote:

Davyd, can Jan help you with the release? Since he is not a PMC member,
there are certain steps he can't take. Though judging from the RELEASING.md
<https://github.com/apache/logging-log4net/blob/master/doc/RELEASING.md>,
maybe he can bring it to a point within the limits of access rights granted
to him, and then you can intervene (e.g., signing artifacts, uploading to
SVN) whenever needed.

If you say this will make things more difficult, that is also
understandable.

On Thu, Feb 29, 2024 at 11:01 AM Davyd McColl 
wrote:


Considering my constrained time, and even though @FreeAndNil
<https://github.com/FreeAndNil> recently stepped up to be a maintainer, I
don't see any time really soon. You can, in the meantime, check out the
repo, build, and distribute a dll with your app if it's that important.
It's not convenient, I'll admit, but if it's urgent, it's an option.

—
Reply to this email directly, view it on GitHub
<https://github.com/apache/logging-log4net/pull/103#issuecomment-1970795467>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAARTSO5BS7Y4XCZS6WAOXLYV36A3AVCNFSM6ABBYRLE4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZQG44TKNBWG4>
.
You are receiving this because you commented.Message ID:

Fwd:

[Davyd McColl]

Apologies, I responded directly to Volkan instead of the list ):


-d



 Forwarded Message 
Subject:Re:
Date:   Tue, 13 Feb 2024 12:00:05 +0200
From:   Davyd McColl 
To: Volkan Yazıcı 



I'd really like to chuck JIRA in a lake of fire and watch it burn slowly /2c

On a less crazy note: I'd really like all the things to be at GitHub - 
it's easier as a dev or a user to get involved.


-d


On 1970/01/01 02:00, wrote:
Log4j has deprecated JIRA in favor of GitHub Issues and enabled GitHub 
Discussions as an alternative (not replacement!) to mailing lists. So 
far it has been a great success[1]. I suggest doing the same for 
Log4cxx and Log4net too. Thoughts? Objections?


Note that I am not talking about only enabling these features. But to 
actively promote them on the website too. Check out the Log4j support 
page <https://logging.apache.org/log4j/2.x/support.html> for an example.


[1] Code was already on GitHub. Now we can refer to PRs, issues, 
commits, code blocks, etc. while having conversations on any GitHub 
text input. I find this quite convenient. IMO, as a result of this 
convenience, I see way more maintainer engagement in PRs and issues. 
Next to that, GitHub Discussions clearly enabled more user 
interactions. It works around the mailing list subscription barrier.

Re: New committer: Fred am Nil (`freeandnil`)

[Davyd McColl]

Welcome Fred!

-d


On 09 February 2024 21:54:45 Fred am Nil  wrote:


Hello,

thank you very much for the warm welcome.
I'm looking forward to collaborating with everyone and making meaningful 
contributions to the Apache Logging Services projects.


Best regards.

Jan

PPK> Welcome, Jan!

PPK> On Fri, 9 Feb 2024 at 20:07, Volkan Yazıcı  wrote:


The Project Management Committee (PMC) for Apache Logging Services has
invited Fred am Nil to become a committer and we are pleased to announce
that they have accepted! 🎉

They have been a long time Log4Net contributor and I am very happy to see
them stepping up to become a maintainer for it. Logging Services
 is more than Log4Net; we have Log4j, Log4cxx,
and several other projects. I am looking forward to their contributions to
all these projects! 🚀

Re: log4net maintainers

[Davyd McColl]

Hi


That would be great! I'd really appreciate the help, and I've obviously 
seen your prior contributions (: There is a process to follow, so we'll 
get that started and get back to you (:



-d


On 2024/01/31 13:01, Fred am Nil wrote:

Hi,

as proposed by Volkan Yazıcı in 
https://github.com/apache/logging-log4net/pull/103#issuecomment-1918677272
I would like to become a maintainer of log4net.

https://github.com/FreeAndNil

Regards.

Fred

Re: [log4net] Project state

[Davyd McColl]

Hi Volkan

That's just me replying wrongly ): I stand by what I said though.

-d

On 2023/11/02 11:13, Volkan Yazıcı wrote:
Davyd, would you mind sharing why you didn't want to send this 
response to the mailing list? If there are no particular reasons, 
could you send it there too, please?


On Wed, Nov 1, 2023 at 1:20 PM Davyd McColl  wrote:

Hi

Yes, I'd agree that log4net is "at risk" seeing as I'm apparently
the only active maintainer - and I'm not even that active, having
not found time in quite a while to do some log4net work ):


-d

On 2023/11/01 13:47, Volkan Yazıcı wrote:

In the board report guidelines
<https://www.apache.org/foundation/board/reporting#guidelines>  
<https://www.apache.org/foundation/board/reporting#guidelines>, project
state is required to be described using the following keywords:

- *New:* a top-level project that's just getting started
- *Ongoing*, with high, moderate or low activity, which you might
quantify if appropriate
- *Dormant:* not much happening on the code, but at least 3 PMC members
ready to engage if needed
- *At risk:* not enough active PMC members, or a significant number of
contributors left the project, etc.
- *Considering moving to the Attic:* a project that's about to move to
the Attic, or discussing that

IMO, Log4net can be classified as "at risk", right?

Re: Docs?

[Davyd McColl]

Ralph, I'd appreciate any help here. Seems there's a permissions error or 
something - sdk docs links return a 403.


-d


On 16 November 2022 23:22:26 Alex Winfield <7nil...@gmail.com> wrote:


 Where should I look for the docs?

All of the examples point to dead links:
https://logging.apache.org/log4net/release/config-examples.html

Sample code online doesn't appear to actually work (%aspnet-context appears
to be parsed as just %a, with "spnet-context" as a static string).

I can see that there definitely is something for handling asp.net contexts (
https://git-wip-us.apache.org/repos/asf?p=logging-log4net.git;a=blob_plain;f=src/log4net/Layout/Pattern/AspNetContextPatternConverter.cs;hb=HEAD),
but I have no idea why it isn't working or what I need to do to enable it.

I'm just very confused on what format properties are available, which may
have been renamed over time, etc

I was able to get what I wanted to work using middleware, but it does feel
weird that there's so little documentation available.  I'd appreciate any
links that could help (I feel like this property is probably already
available and not need an entire middleware just to hook into log4net lol)

Also, log4net-u...@logging.apache.org appears to not have anyone watching
answering questions.  If it isn't being used, it should probably be removed
from the docs as a valid way to get help.

Re: log4net 2.0.15 vote

[Davyd McColl]

Hi all

Thanks for the votes, 2.0.15 is now live.
-d
On Aug 4 2022, at 5:14 am, Davyd McColl  wrote:
>
> Hi Ralph
> Yes, I'll release as soon as I get a gap. I replied to the signing request 
> too - not sure what happened to 2.0.14, but every other release is signed. 
> The signing attribute was missing - I must have accidentally deleted it - 
> I've added a test to check that it's in place and checked that the RC 
> artifact assemblies are signed (that's the mystery: they are signed, even 
> though I just added the signing attribute back 🤔. Oh well, now there's a test 
> for it and tests are run as part of the release artifact generation, so if it 
> happens again, at least I'll know).
> -e
>
> On 03 August 2022 22:00:34 Ralph Goers  wrote:
> > Doesn’t this vote have the necessary 3 +1 votes? Davyd, I am assuming as 
> > release manager you will be voting +1.
> > However, see the request to sign stuff going to Nuget. You may want to do 
> > that before you send it there.
> > Ralph
> > > On Jul 28, 2022, at 10:06 AM, Matt Sicker  wrote:
> > > Same here. I can review over the weekend.
> > > On Thu, Jul 28, 2022 at 9:51 AM Ralph Goers  
> > > wrote:
> > >
> > > >
> > > > I haven’t forgotten about this, but I may not be able to look at it 
> > > > until Saturday.
> > > > Ralph
> > > > > On Jul 26, 2022, at 6:25 PM, Robert Middleton  
> > > > > wrote:
> > > > > The binaries won't show up under downloads.apache.org 
> > > > > (http://downloads.apache.org) until actually
> > > > > released(e.g. under repos/dist/release/logging/log4net). That can of
> > > > > course only happen after the release is done via this vote.
> > > > >
> > > > > I'll take a look at it in a bit just to validate that the signatures
> > > > > are good, as I know nothing about .net development.
> > > > >
> > > > > -Robert Middleton
> > > > > On Mon, Jul 25, 2022 at 5:45 AM Davyd McColl
> > > > >  wrote:
> > > > >
> > > > > >
> > > > > > Hi all
> > > > > > It's been a while, but I've finally tied together some work in a 
> > > > > > 2.0.15 release for log4net. An rc tag is up at GitHub with details: 
> > > > > > https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.15-rc1
> > > > > > I've pushed docs to staging as well as binaries to 
> > > > > > https://dist.apache.org/repos/dist/dev/logging/log4net, however
> > > > > > I don't see the 2.0.15 artifacts up at 
> > > > > > https://downloads.apache.org/logging/log4net
> > > > > >
> > > > > > This is probably why download links from 
> > > > > > https://logging.staged.apache.org/log4net/download_log4net.html 
> > > > > > aren't working?
> > > > > > @Ralph, I'd appreciate any assistance here - I'm probably missing 
> > > > > > something obvious ):
> > > > > > Thanks
> > > > > > -d
> > > > > >
> > > > >
> > > >
> > >
> >
>
>

Re: log4net 2.0.15 vote

[Davyd McColl]

Hi Ralph

Yes, I'll release as soon as I get a gap. I replied to the signing request 
too - not sure what happened to 2.0.14, but every other release is signed. 
The signing attribute was missing - I must have accidentally deleted it - 
I've added a test to check that it's in place and checked that the RC 
artifact assemblies are signed (that's the mystery: they are signed, even 
though I just added the signing attribute back 🤔. Oh well, now there's a 
test for it and tests are run as part of the release artifact generation, 
so if it happens again, at least I'll know).


-e


On 03 August 2022 22:00:34 Ralph Goers  wrote:

Doesn’t this vote have the necessary 3 +1 votes? Davyd, I am assuming as 
release manager you will be voting +1.


However, see the request to sign stuff going to Nuget. You may want to do 
that before you send it there.


Ralph


On Jul 28, 2022, at 10:06 AM, Matt Sicker  wrote:

Same here. I can review over the weekend.

On Thu, Jul 28, 2022 at 9:51 AM Ralph Goers  wrote:


I haven’t forgotten about this, but I may not be able to look at it until 
Saturday.


Ralph


On Jul 26, 2022, at 6:25 PM, Robert Middleton  wrote:

The binaries won't show up under downloads.apache.org until actually
released(e.g. under repos/dist/release/logging/log4net).  That can of
course only happen after the release is done via this vote.

I'll take a look at it in a bit just to validate that the signatures
are good, as I know nothing about .net development.

-Robert Middleton

On Mon, Jul 25, 2022 at 5:45 AM Davyd McColl
 wrote:


Hi all

It's been a while, but I've finally tied together some work in a 2.0.15 
release for log4net. An rc tag is up at GitHub with details: 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.15-rc1
I've pushed docs to staging as well as binaries to 
https://dist.apache.org/repos/dist/dev/logging/log4net, however
I don't see the 2.0.15 artifacts up at 
https://downloads.apache.org/logging/log4net


This is probably why download links from 
https://logging.staged.apache.org/log4net/download_log4net.html aren't working?


@Ralph, I'd appreciate any assistance here - I'm probably missing something 
obvious ):


Thanks
-d

Re: [VOTE] Release log4net 2.0.15

[Davyd McColl]

It is on GitHub (both in git and zip at the release), but having checked out 
the svn repo at https://dist.apache.org/repos/dist/release/logging/ on this 
machine, I don't see the 2.0.15 artifacts that I added the other day, and that 
comes back to my question about them not showing up in the d/l locations :/ 
obviously, I'm doing Something Wrong.

I've re-committed from my linux machine - perhaps with better effect?
-d
On Jul 29 2022, at 10:37 pm, Ralph Goers  wrote:
> Also, is the web site being updated for the release. While not required for a 
> release we usually have a web site to review with a release.
>
> Ralph
> > On Jul 29, 2022, at 1:36 PM, Ralph Goers  wrote:
> >
> > Where is the zip of the source? The ASF releases source code. Binaries are 
> > for the user’s convenience.
> >
> > Ralph
> >
> >> On Jul 26, 2022, at 6:25 PM, Robert Middleton  
> >> wrote:
> >>
> >> The binaries won't show up under downloads.apache.org until actually
> >> released(e.g. under repos/dist/release/logging/log4net). That can of
> >> course only happen after the release is done via this vote.
> >>
> >> I'll take a look at it in a bit just to validate that the signatures
> >> are good, as I know nothing about .net development.
> >>
> >> -Robert Middleton
> >>
> >> On Mon, Jul 25, 2022 at 5:45 AM Davyd McColl
> >>  wrote:
> >>>
> >>> Hi all
> >>>
> >>> It's been a while, but I've finally tied together some work in a 2.0.15 
> >>> release for log4net. An rc tag is up at GitHub with details: 
> >>> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.15-rc1
> >>> I've pushed docs to staging as well as binaries to 
> >>> https://dist.apache.org/repos/dist/dev/logging/log4net, however
> >>> I don't see the 2.0.15 artifacts up at 
> >>> https://downloads.apache.org/logging/log4net
> >>>
> >>> This is probably why download links from 
> >>> https://logging.staged.apache.org/log4net/download_log4net.html aren't 
> >>> working?
> >>>
> >>> @Ralph, I'd appreciate any assistance here - I'm probably missing 
> >>> something obvious ):
> >>>
> >>> Thanks
> >>> -d
> >
>

Re: [VOTE] Release log4net 2.0.15

[Davyd McColl]

I don't understand? There is an update at the staging site? What am I missing?

-d
On Jul 29 2022, at 10:37 pm, Ralph Goers  wrote:
> Also, is the web site being updated for the release. While not required for a 
> release we usually have a web site to review with a release.
>
> Ralph
> > On Jul 29, 2022, at 1:36 PM, Ralph Goers  wrote:
> >
> > Where is the zip of the source? The ASF releases source code. Binaries are 
> > for the user’s convenience.
> >
> > Ralph
> >
> >> On Jul 26, 2022, at 6:25 PM, Robert Middleton  
> >> wrote:
> >>
> >> The binaries won't show up under downloads.apache.org until actually
> >> released(e.g. under repos/dist/release/logging/log4net). That can of
> >> course only happen after the release is done via this vote.
> >>
> >> I'll take a look at it in a bit just to validate that the signatures
> >> are good, as I know nothing about .net development.
> >>
> >> -Robert Middleton
> >>
> >> On Mon, Jul 25, 2022 at 5:45 AM Davyd McColl
> >>  wrote:
> >>>
> >>> Hi all
> >>>
> >>> It's been a while, but I've finally tied together some work in a 2.0.15 
> >>> release for log4net. An rc tag is up at GitHub with details: 
> >>> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.15-rc1
> >>> I've pushed docs to staging as well as binaries to 
> >>> https://dist.apache.org/repos/dist/dev/logging/log4net, however
> >>> I don't see the 2.0.15 artifacts up at 
> >>> https://downloads.apache.org/logging/log4net
> >>>
> >>> This is probably why download links from 
> >>> https://logging.staged.apache.org/log4net/download_log4net.html aren't 
> >>> working?
> >>>
> >>> @Ralph, I'd appreciate any assistance here - I'm probably missing 
> >>> something obvious ):
> >>>
> >>> Thanks
> >>> -d
> >
>

[VOTE] Release log4net 2.0.15

[Davyd McColl]

Hi all

It's been a while, but I've finally tied together some work in a 2.0.15 release 
for log4net. An rc tag is up at GitHub with details: 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.15-rc1
I've pushed docs to staging as well as binaries to 
https://dist.apache.org/repos/dist/dev/logging/log4net, however
I don't see the 2.0.15 artifacts up at 
https://downloads.apache.org/logging/log4net

This is probably why download links from 
https://logging.staged.apache.org/log4net/download_log4net.html aren't working?

@Ralph, I'd appreciate any assistance here - I'm probably missing something 
obvious ):

Thanks
-d

Re: EventLogAppender is missing in .NET (not Framework)

[Davyd McColl]

Hi Vladimir

Yes, you're correct that the event log appender isn't available in the 
netstandard version of log4net because it's not cross-platform.
Right now, I don't have capacity to build one (I have outstanding work I'd like 
to do in log4net as it is), so the best suggestions I can give are:
If Log4Net.Appenders.NetCore still works adequately, then use it. Windows event 
logging has pretty-much stayed the same for many years and is unlikely to 
change because it would break a lot of things. Since the code is open-source, 
you could choose to use the nuget package (though you may have to implement 
assembly bindings) or you could copy-paste the code from 
https://github.com/robsonj/Log4Net.Appenders/blob/master/Log4Net.Appenders.NetCore/EventLogAppender.cs
 into your project. Licensing appears to be MIT from the csproj, though there's 
no LICENSE file in the repo. There's also a fork at 
https://github.com/JTOne123/Log4Net.Appenders which was updated a little more 
recently.
You could contribute, either by helping to revive Log3Net.Appenders.NetCore, or 
by creating a new package - the smaller and more accurately-named, the better, 
so I'd suggest something like Log4Net.EventLogAppender.NetCore - with only this 
appender in it and get that up at nuget.org. Sincee it brings in the extra 
package reference for System.Diagnostics.EventLog, I wouldn't want to include 
this directly in log4net, forcing more package dependencies than many people 
would want. Indeed, this is how I was first introduced to working with log4net 
- I wrote https://www.nuget.org/packages/Chillisoft.splunk4net, which isn't 
maintained any more because I left the company and it's their project (and I 
don't use splunk any more either). However, it's an example of what you could 
do.

Hope this helps
-d

On Jul 15 2022, at 10:42 am, Vladimir Ryabtsev  wrote:
> Hi,
>
> EventLogAppender is listed in the official documentation, with examples (
> https://logging.apache.org/log4net/release/config-examples.html#eventlogappender),
> but someone trying to configure this appender in a .NET (not Framework)
> application quickly finds out that this class is missing from the library.
> With .NET being now the recommended target framework by Microsoft (
> https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/versions-and-dependencies),
> it is unclear how to use this appender in .NET applications. The
> documentation does not provide any clue on that, and does not even mention
> that this appender is available only in .NET Framework version of log4net.
>
> Looking into the code, this class is commented in the netstandard/log4net
> project (
> https://git-wip-us.apache.org/repos/asf?p=logging-log4net.git;a=blob_plain;f=netstandard/log4net/log4net.xproj;hb=HEAD).
> I can guess it was made in order to avoid pulling Windows-specific
> dependencies, however I cannot find what is the alternative provided by the
> project.
>
> So far I found Log4Net.Appenders.NetCore package that fills the gap with
> the missing appender, but this package seems community-driven and abandoned
> (not maintained for 4 years), though works.
>
> Please suggest what is the best way of using EventLogAppender in modern
> .NET applications. Writing to Event Log is a requirement on my project.
>
> Thank you,
> Vladimir
>

Re: Re: [Newsletter] Re: log4net - performance hit because UserName is fetched always

[Davyd McColl]

ch to 
show what I mean?

Btw: beginner question: how do I answer properly in order to append my answer 
to the current thread in the mailing list, rather than creating a new thread on 
each response?

Thank you guys
Denis


From: Davyd McColl mailto:dav...@gmail.com]>
Sent: Tuesday, February 22, 2022 3:29 PM
To: dev@logging.apache.org [mailto:dev@logging.apache.org]
Cc: Petker Denis 8BM3 mailto:denis.pet...@rohde-schwarz.com]>
Subject: *EXT* Re: [Newsletter] Re: log4net - performance hit because UserName 
is fetched always

Hi Vladimir

That's a very good point - the thread could be impersonating a user 
(https://docs.microsoft.com/en-us/dotnet/api/system.security.principal.windowsidentity.getcurrent
 
[https://docs.microsoft.com/en-us/dotnet/api/system.security.principal.windowsidentity.getcurrent]),
and I could imagine this being the user for an asp.net [http://asp.net] request 
if it's tied into windows identities. It is not the case for my work sites, 
where `WindowsIdentity.GetCurrent()`
returns the "IIS AppPool" user (IIS APPPool\{pool name})

So it would seem that caching it isn't an option. It also looks like the value 
is only calculated when read, so if it's not part of the logging pattern, I 
don't see the problem?
Denis, can you elaborate on the use-case please? If your application never 
impersonates, the value seems, to me, to have little value in logs, and if it 
does impersonate,
then it should be updated. The edge case is multiple applications using the 
same log4net configuration, without impersonation, where the user name may 
change between
runs but not during the run of the process. Perhaps there should be two 
properties: one cached and one not, bearing in mind that the original behavior 
of the existing
UserName property (uncached) should probably be retained for the principle of 
Least Surprise.

-d

On 2022-02-22 15:56:11, Vladimir Vedeneev mailto:lanor...@gmail.com]<mailto:lanor...@gmail.com 
[mailto:lanor...@gmail.com]>> wrote:
Sorry if will be saying dumb things here, as I've seen that several years
ago and have no time to review that now; but maybe that'll ring the bell
for somebody

I thought that UserName could be related to user name from principal (thus
basically anything set in code - and can be easily different for the same
thread in say asp.net [http://asp.net] environment), not the windows user name 
of the process

Thanks,
Vladimir

On Tue, 22 Feb 2022 at 14:26, Dominik Psenner wrote:

> I believe the caching has already been implemented but don't have any
> references to mention right now.
>
> On Tue, 22 Feb 2022 at 09:56, Denis Petker
> >
> wrote:
>
> > Hi Davyd
> >
> > Thanks for the quick response! Agreed, I also don't think, that the
> > username doesn't change for a process.
> > If we say, that the username isn't going to change for a process, I think
> > there is no reason in printing the user name per log statement. However,
> > the ticket LOG4NET-205 has been raised by someone, who obviously was
> > interested in filtering log events by username?
> >
> > So what you mean technically is to retrieve the username once at startup
> > and cache for the remaining runtime? In order to be backward compatible,
> we
> > then still need to maintain the UserName property in the LoggingEvent
> class
> > I guess. So the username would then be provided to LoggingEvent objects
> > from whatever is creating them?
> >
> >
> > -Original Message-
> > From: Davyd McColl
> > Sent: Monday, February 21, 2022 6:43 PM
> > To: dev@logging.apache.org 
> > [mailto:dev@logging.apache.org]<mailto:dev@logging.apache.org 
> > [mailto:dev@logging.apache.org]>; Petker Denis 8BM3 <
> > denis.pet...@rohde-schwarz.com 
> > [mailto:denis.pet...@rohde-schwarz.com]<mailto:denis.pet...@rohde-schwarz.com
> >  [mailto:denis.pet...@rohde-schwarz.com]>>
> > Subject: *EXT* [Newsletter] Re: log4net - performance hit because
> UserName
> > is fetched always
> >
> > Hi Denis
> >
> > Thanks for the report (:
> > I'm happy to review contributions, though for this particular issue, it
> > seems like the resolution is to cache the resolved user name, rather than
> > allowing specifying the name via config. The whole point of this property
> > is to log the username under which the process is run (: The username
> for a
> > process isn't going to change (at least, I'm not aware of a process for
> > doing so), so it feels like the correct approach is simply to cache.
> Please
> > feel free to raise a PR at github. I recognise that I'm not the fastest
> > responder - there's just one of me and it seems like there

Re: [Newsletter] Re: log4net - performance hit because UserName is fetched always

[Davyd McColl]

Hi Vladimir

That's a very good point - the thread could be impersonating a user 
(https://docs.microsoft.com/en-us/dotnet/api/system.security.principal.windowsidentity.getcurrent),
 
and I could imagine this being the user for an asp.net request if it's tied 
into windows identities. It is not the case for my work sites, where 
`WindowsIdentity.GetCurrent()`
returns the "IIS AppPool" user (IIS APPPool\{pool name})

So it would seem that caching it isn't an option. It also looks like the value 
is only calculated when read, so if it's not part of the logging pattern, I 
don't see the problem? 
Denis, can you elaborate on the use-case please? If your application never 
impersonates, the value seems, to me, to have little value in logs, and if it 
does impersonate,
then it should be updated. The edge case is multiple applications using the 
same log4net configuration, without impersonation, where the user name may 
change between
runs but not during the run of the process. Perhaps there should be two 
properties: one cached and one not, bearing in mind that the original behavior 
of the existing
UserName property (uncached) should probably be retained for the principle of 
Least Surprise.

-d

On 2022-02-22 15:56:11, Vladimir Vedeneev  wrote:
Sorry if will be saying dumb things here, as I've seen that several years
ago and have no time to review that now; but maybe that'll ring the bell
for somebody

I thought that UserName could be related to user name from principal (thus
basically anything set in code - and can be easily different for the same
thread in say asp.net environment), not the windows user name of the process

Thanks,
Vladimir

On Tue, 22 Feb 2022 at 14:26, Dominik Psenner wrote:

> I believe the caching has already been implemented but don't have any
> references to mention right now.
>
> On Tue, 22 Feb 2022 at 09:56, Denis Petker
> >
> wrote:
>
> > Hi Davyd
> >
> > Thanks for the quick response! Agreed, I also don't think, that the
> > username doesn't change for a process.
> > If we say, that the username isn't going to change for a process, I think
> > there is no reason in printing the user name per log statement. However,
> > the ticket LOG4NET-205 has been raised by someone, who obviously was
> > interested in filtering log events by username?
> >
> > So what you mean technically is to retrieve the username once at startup
> > and cache for the remaining runtime? In order to be backward compatible,
> we
> > then still need to maintain the UserName property in the LoggingEvent
> class
> > I guess. So the username would then be provided to LoggingEvent objects
> > from whatever is creating them?
> >
> >
> > -Original Message-
> > From: Davyd McColl
> > Sent: Monday, February 21, 2022 6:43 PM
> > To: dev@logging.apache.org; Petker Denis 8BM3 <
> > denis.pet...@rohde-schwarz.com>
> > Subject: *EXT* [Newsletter] Re: log4net - performance hit because
> UserName
> > is fetched always
> >
> > Hi Denis
> >
> > Thanks for the report (:
> > I'm happy to review contributions, though for this particular issue, it
> > seems like the resolution is to cache the resolved user name, rather than
> > allowing specifying the name via config. The whole point of this property
> > is to log the username under which the process is run (: The username
> for a
> > process isn't going to change (at least, I'm not aware of a process for
> > doing so), so it feels like the correct approach is simply to cache.
> Please
> > feel free to raise a PR at github. I recognise that I'm not the fastest
> > responder - there's just one of me and it seems like there's always
> > something vying for my attention - but I do try to respond to pull
> requests
> > as quickly as possible.
> > I have another fix in the works for xml layouts anyway, though I was
> > pursuing that with respect to another reported issue, but I could let
> that
> > issue go for now for a hastier release.
> > -d
> > On Feb 21 2022, at 7:22 pm, Denis Petker
> >
> > wrote:
> > >
> > > Hi all,
> > >
> > > we have upgraded the log4net version from 1.2.10 to the newest version
> > 2.0.14 and are now facing performace issues. I already have done some
> > investigation looking at the log4net code.
> > > With the ticket LOG4NET-205 (
> > https://issues.apache.org/jira/browse/LOG4NET-205) a change has been
> > introduced, which makes log4net not acceptable for us in terms of
> > performance. (Commit 5c023f6a22bfb93873a5ce0d6f5ac7e7275e2914) The change
> > has been done in ord

RE: [Newsletter] [Newsletter] Re: log4net - performance hit because UserName is fetched always

[Davyd McColl]

Hi Denis

Added as commit 025d7f6ac197fc8ca92c776b14d9205d6b899168 - I'll release as soon 
as I get the time (:

-d

On 2022-02-22 12:36:47, Denis Petker  wrote:
Hi Davyd,

your patch looks good to me. It resolves my issue.
Would be great if it could go into the next release.

Many thanks,
Denis

--
Denis Petker
Next Generation Solutions | 8BM3

Rohde & Schwarz GmbH & Co. KG
Hanomaghof 1 | 30449 Hanover
Phone: +49 511 678 07 146 | Fax: +49 511 678 07 200
Internet: www.rohde-schwarz.com


Geschäftsführung / Executive Board: Christian Leicher (Vorsitzender / 
Chairman), Peter Riedel, Sitz der Gesellschaft / Company's Place of Business: 
München, Registereintrag / Commercial Register No.: HRA 16 270, Persönlich 
haftender Gesellschafter / Personally Liable Partner: RUSEG Verwaltungs-GmbH, 
Sitz der Gesellschaft / Company's Place of Business: München, Registereintrag / 
Commercial Register No.: HRB 7 534, Umsatzsteuer-Identifikationsnummer 
(USt-IdNr.) / VAT Identification No.: DE 130 256 683, Elektro-Altgeräte 
Register (EAR) / WEEE Register No.: DE 240 437 86

From: Davyd McColl
Sent: Tuesday, February 22, 2022 10:22 AM
To: dev@logging.apache.org
Cc: Petker Denis 8BM3
Subject: *EXT* [Newsletter] RE: [Newsletter] Re: log4net - performance hit 
because UserName is fetched always

Hi Denis

I would imagine that the use case is for shared logging config between 
processes.

I think that the issue could be resolved by some caching in 
LoggingEvent.TryGetCurrentUserName (LoggingEvent.cs:927).
I was just going to provide guidance, but it's probably quicker to just patch 
and test (:

If you have the time, could you test the attached patch?

Thanks
-d

On 2022-02-22 10:56:24, Denis Petker <>> wrote:
Hi Davyd

Thanks for the quick response! Agreed, I also don't think, that the username 
doesn't change for a process.
If we say, that the username isn't going to change for a process, I think there 
is no reason in printing the user name per log statement. However, the ticket 
LOG4NET-205 has been raised by someone, who obviously was interested in 
filtering log events by username?

So what you mean technically is to retrieve the username once at startup and 
cache for the remaining runtime? In order to be backward compatible, we then 
still need to maintain the UserName property in the LoggingEvent class I guess. 
So the username would then be provided to LoggingEvent objects from whatever is 
creating them?


-Original Message-
From: Davyd McColl
Sent: Monday, February 21, 2022 6:43 PM
To: dev@logging.apache.org; Petker Denis 8BM3
Subject: *EXT* [Newsletter] Re: log4net - performance hit because UserName is 
fetched always

Hi Denis

Thanks for the report (:
I'm happy to review contributions, though for this particular issue, it seems 
like the resolution is to cache the resolved user name, rather than allowing 
specifying the name via config. The whole point of this property is to log the 
username under which the process is run (: The username for a process isn't 
going to change (at least, I'm not aware of a process for doing so), so it 
feels like the correct approach is simply to cache. Please feel free to raise a 
PR at github. I recognise that I'm not the fastest responder - there's just one 
of me and it seems like there's always something vying for my attention - but I 
do try to respond to pull requests as quickly as possible.
I have another fix in the works for xml layouts anyway, though I was pursuing 
that with respect to another reported issue, but I could let that issue go for 
now for a hastier release.
-d
On Feb 21 2022, at 7:22 pm, Denis Petker wrote:
>
> Hi all,
>
> we have upgraded the log4net version from 1.2.10 to the newest version 2.0.14 
> and are now facing performace issues. I already have done some investigation 
> looking at the log4net code.
> With the ticket LOG4NET-205 
> (https://issues.apache.org/jira/browse/LOG4NET-205) a change has been 
> introduced, which makes log4net not acceptable for us in terms of 
> performance. (Commit 5c023f6a22bfb93873a5ce0d6f5ac7e7275e2914) The change has 
> been done in order to be able to use UserName and Identity in the 
> PropertyFilter. It adds 'internal' properties representing the UserName and 
> Identity to the m_compositeProperties so that they are now accessible in the 
> PropertyFilter. That works as intended so far. See the attached diff 
> illustrating the change.
>
> The problem is, that fetching the UserName from the system is pretty 
> expensive. With the change above UserName is fetched always, regardless of 
> whether we use UserName or not. I did some benchmarking and this change 
> slowed down logging by a factor of 60. I also don’t see any way to get around 
> this by changing the configuration. I believe this ca

RE: [Newsletter] Re: log4net - performance hit because UserName is fetched always

[Davyd McColl]

Hi Denis

I would imagine that the use case is for shared logging config between 
processes.

I think that the issue could be resolved by some caching in 
LoggingEvent.TryGetCurrentUserName (LoggingEvent.cs:927). 
I was just going to provide guidance, but it's probably quicker to just patch 
and test (:

If you have the time, could you test the attached patch?

Thanks
-d
On 2022-02-22 10:56:24, Denis Petker  wrote:
Hi Davyd

Thanks for the quick response! Agreed, I also don't think, that the username 
doesn't change for a process.
If we say, that the username isn't going to change for a process, I think there 
is no reason in printing the user name per log statement. However, the ticket 
LOG4NET-205 has been raised by someone, who obviously was interested in 
filtering log events by username?

So what you mean technically is to retrieve the username once at startup and 
cache for the remaining runtime? In order to be backward compatible, we then 
still need to maintain the UserName property in the LoggingEvent class I guess. 
So the username would then be provided to LoggingEvent objects from whatever is 
creating them?


-Original Message-
From: Davyd McColl
Sent: Monday, February 21, 2022 6:43 PM
To: dev@logging.apache.org; Petker Denis 8BM3
Subject: *EXT* [Newsletter] Re: log4net - performance hit because UserName is 
fetched always

Hi Denis

Thanks for the report (:
I'm happy to review contributions, though for this particular issue, it seems 
like the resolution is to cache the resolved user name, rather than allowing 
specifying the name via config. The whole point of this property is to log the 
username under which the process is run (: The username for a process isn't 
going to change (at least, I'm not aware of a process for doing so), so it 
feels like the correct approach is simply to cache. Please feel free to raise a 
PR at github. I recognise that I'm not the fastest responder - there's just one 
of me and it seems like there's always something vying for my attention - but I 
do try to respond to pull requests as quickly as possible.
I have another fix in the works for xml layouts anyway, though I was pursuing 
that with respect to another reported issue, but I could let that issue go for 
now for a hastier release.
-d
On Feb 21 2022, at 7:22 pm, Denis Petker wrote:
>
> Hi all,
>
> we have upgraded the log4net version from 1.2.10 to the newest version 2.0.14 
> and are now facing performace issues. I already have done some investigation 
> looking at the log4net code.
> With the ticket LOG4NET-205 
> (https://issues.apache.org/jira/browse/LOG4NET-205) a change has been 
> introduced, which makes log4net not acceptable for us in terms of 
> performance. (Commit 5c023f6a22bfb93873a5ce0d6f5ac7e7275e2914) The change has 
> been done in order to be able to use UserName and Identity in the 
> PropertyFilter. It adds 'internal' properties representing the UserName and 
> Identity to the m_compositeProperties so that they are now accessible in the 
> PropertyFilter. That works as intended so far. See the attached diff 
> illustrating the change.
>
> The problem is, that fetching the UserName from the system is pretty 
> expensive. With the change above UserName is fetched always, regardless of 
> whether we use UserName or not. I did some benchmarking and this change 
> slowed down logging by a factor of 60. I also don’t see any way to get around 
> this by changing the configuration. I believe this can only be fixed by 
> changing code.
>
> I would suggest, rather than adding 'internal' properties to 
> m_compositeProperties, we should make the function 
> LoggingEvent.LookupProperty to look after the native properties, when 
> corresponding keys are specified. E.g. when the key "UserName" is specified, 
> we could return the value of the property LoggingEvent.UserName etc.
>
> In the meantime we want to use a changed version of log4net for our purposes. 
> I wonder, whether this change could be integrated into the official version? 
> I’ve never contributed to a public github project before, so don’t know how 
> to proceed really.
>
> Thanks,
> Denis
>
>
> This is the historic change causing the problem.
>
>
> --
> Denis Petker
> Next Generation Solutions | 8BM3
>
>
>
> Rohde & Schwarz GmbH & Co. KG
> Hanomaghof 1 | 30449 Hanover
> Phone: +49 511 678 07 146 | Fax: +49 511 678 07 200
> Internet: www.rohde-schwarz.com (http://www.rohde-schwarz.com/)
>
> 
> Geschäftsführung / Executive Board: Christian Leicher (Vorsitzender / 
> Chairman), Peter Riedel, Sitz der Gesellschaft / Company's Place of Business: 
> München, Registereintrag / Commercial Register No.: HRA 16 270, 

Re: log4net - performance hit because UserName is fetched always

[Davyd McColl]

Hi Denis

Thanks for the report (:
I'm happy to review contributions, though for this particular issue, it seems 
like the resolution is to cache the resolved user name, rather than allowing 
specifying the name via config. The whole point of this property is to log the 
username under which the process is run (: The username for a process isn't 
going to change (at least, I'm not aware of a process for doing so), so it 
feels like the correct approach is simply to cache. Please feel free to raise a 
PR at github. I recognise that I'm not the fastest responder - there's just one 
of me and it seems like there's always something vying for my attention - but I 
do try to respond to pull requests as quickly as possible.
I have another fix in the works for xml layouts anyway, though I was pursuing 
that with respect to another reported issue, but I could let that issue go for 
now for a hastier release.
-d
On Feb 21 2022, at 7:22 pm, Denis Petker  wrote:
>
> Hi all,
>
> we have upgraded the log4net version from 1.2.10 to the newest version 2.0.14 
> and are now facing performace issues. I already have done some investigation 
> looking at the log4net code.
> With the ticket LOG4NET-205 
> (https://issues.apache.org/jira/browse/LOG4NET-205) a change has been 
> introduced, which makes log4net not acceptable for us in terms of 
> performance. (Commit 5c023f6a22bfb93873a5ce0d6f5ac7e7275e2914) The change has 
> been done in order to be able to use UserName and Identity in the 
> PropertyFilter. It adds 'internal' properties representing the UserName and 
> Identity to the m_compositeProperties so that they are now accessible in the 
> PropertyFilter. That works as intended so far. See the attached diff 
> illustrating the change.
>
> The problem is, that fetching the UserName from the system is pretty 
> expensive. With the change above UserName is fetched always, regardless of 
> whether we use UserName or not. I did some benchmarking and this change 
> slowed down logging by a factor of 60. I also don’t see any way to get around 
> this by changing the configuration. I believe this can only be fixed by 
> changing code.
>
> I would suggest, rather than adding 'internal' properties to 
> m_compositeProperties, we should make the function 
> LoggingEvent.LookupProperty to look after the native properties, when 
> corresponding keys are specified. E.g. when the key "UserName" is specified, 
> we could return the value of the property LoggingEvent.UserName etc.
>
> In the meantime we want to use a changed version of log4net for our purposes. 
> I wonder, whether this change could be integrated into the official version? 
> I’ve never contributed to a public github project before, so don’t know how 
> to proceed really.
>
> Thanks,
> Denis
>
>
> This is the historic change causing the problem.
>
>
> --
> Denis Petker
> Next Generation Solutions | 8BM3
>
>
>
> Rohde & Schwarz GmbH & Co. KG
> Hanomaghof 1 | 30449 Hanover
> Phone: +49 511 678 07 146 | Fax: +49 511 678 07 200
> Internet: www.rohde-schwarz.com (http://www.rohde-schwarz.com/)
>
> 
> Geschäftsführung / Executive Board: Christian Leicher (Vorsitzender / 
> Chairman), Peter Riedel, Sitz der Gesellschaft / Company's Place of Business: 
> München, Registereintrag / Commercial Register No.: HRA 16 270, Persönlich 
> haftender Gesellschafter / Personally Liable Partner: RUSEG Verwaltungs-GmbH, 
> Sitz der Gesellschaft / Company's Place of Business: München, Registereintrag 
> / Commercial Register No.: HRB 7 534, Umsatzsteuer-Identifikationsnummer 
> (USt-IdNr.) / VAT Identification No.: DE 130 256 683, Elektro-Altgeräte 
> Register (EAR) / WEEE Register No.: DE 240 437 86
>
>

Re: [VOTE] Future of Log4j 1.x

[Davyd McColl]

+1, option 1

Apologies for the delay, took me a while to find the original email.

-d


On December 29, 2021 21:33:35 "Christian Grobmeier"  
wrote:



Hello,

as discussed in another thread, this is a vote about the future of log4j 1. 
This vote stays open for the usual 72h.

Options are explained below.

You can vote for:

 [ ] +1, Option 1
 [ ] +1, Option 2
 [ ] +/- 0, abstain
 [ ] -1 object against those options

Option 1: Create a README.md that publishes the projects EOL status and do 
nothing else.
Option 2: Create a README which says the project is EOL but allow the 
following work for 1.2.18 AND create a full release:

a.  Make the build work with a modern version of Maven.
b.  Fix the Java version bug.
c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
d.  Fix CVE-2019-17571

Regards,
Christian
--
The Apache Software Foundation
V.P., Data Privacy

Re: [DISCUSS] Starting social media accounts for subprojects

[Davyd McColl]

+1 for accounts per project

-d


On December 31, 2021 01:02:08 Remko Popma  wrote:


I also like this idea and agree with separate accounts for each component.

On Fri, Dec 31, 2021 at 7:48 AM Gary Gregory  wrote:


Great idea. I would suggest one account for the each component. I'm not
sure anyone but the PMC would care about a logging services account.

Gary

On Thu, Dec 30, 2021, 17:40 Matt Sicker  wrote:

> We recently had an idea discussed on a video call about potentially
> starting some Twitter et al. accounts for announcing releases, release
> candidates, and larger upcoming changes to subprojects (e.g., changing
the
> minimum major version of the underlying programming language or build
> tooling, major version releases like 2.x -> 3.x, etc). While the dev list
> remains our official place to discuss development, it would be immensely
> useful for communicating with our wider user base about changes that may
be
> more relevant to them than to active developers and contributors.
>
> What do you all think? If we do make accounts, would it make sense to
> divide them into accounts like @log4j, @log4net, @log4cxx, etc., or
should
> they be created like a common account for the whole Logging PMC? And
which
> social media sites would be best to use here? Twitter is an obvious
choice,
> but there could also be other tech-heavy social media sites that would
also
> benefit.
> --
> Matt Sicker
>
>

Re: [VOTE] Release log4net 2.0.14

[Davyd McColl]

Thanks Matt, then I'd consider this vote closed and the release ready to go 
as soon as I get to it (probably the end of the week).


Thanks to everyone who double-checked me.

-d


On December 29, 2021 02:23:16 Matt Sicker  wrote:


Yeah, you can close the vote before releasing.
--
Matt Sicker


On Dec 28, 2021, at 16:11, Davyd McColl  wrote:

Hi Matt, I'm happy to, just need to get the time to do the actually release 
(: holiday mode has kicked in good and proper. Can I close out before I 
release?


-d


On December 28, 2021 21:37:21 Matt Sicker  wrote:

Seems like we have enough votes to complete this release. Davyd, would you 
like to close the vote?

--
Matt Sicker


On Dec 25, 2021, at 14:50, Remko Popma  wrote:
+1
On Sat, Dec 25, 2021 at 6:35 AM Ralph Goers 
wrote:

+1
I checked the signature and hashes and those look good.
I unzipped the source and binaries. The appropriate license and notice
files are present.
I did not perform tests as I don’t have the necessary tools installed.
Ralph

On Dec 23, 2021, at 1:36 PM, Matt Sicker  wrote:
Root keys are in https://downloads.apache.org/logging/KEYS which is in
the dist repository where you commit releases.
On Mon, Dec 20, 2021 at 2:03 AM Dominik Psenner 

wrote:

* old-log4net.snk.gpg has been the old key to sign binaries.
* @Matt, where is the root logging KEYS file located?
The changes in the release look good to me. +1
On Mon, 20 Dec 2021 at 07:34, Davyd McColl  wrote:

Thanks Matt
Since you've given a +1, I'll write up some sticky notes to address

these

points in the near future.
-d
On December 19, 2021 23:51:45 Matt Sicker  wrote:

+1
Notes on the release:
* I’ve copied your release signing key to the root logging KEYS file

for

easier discoverability.
* The copyright year in the NOTICE file is a few years out of date at

this

point. I’ve updated this in master, though you’ll want to update this

again

in a couple weeks when it’s outdated again.
* Some included files in the base directory of the source zip are

missing

copyright headers or shouldn’t even be included in the tarball (e.g.,

the

appveyor config file probably isn’t necessary)
- Not sure what old-log4net.snk.gpg is in there for, either.
- Gulp task source files missing headers
* Artifact signatures and sha512 hashes look good (checked with shasum
which is the Perl script version), contain appropriate LICENSE and

NOTICE

(besides the outdated copyright year, but not a blocker), no binaries

in

the source zip, appropriate files in the binary zip.
--
Matt Sicker

On Dec 16, 2021, at 07:47, Davyd McColl  wrote:
Hi all
I'd like to raise a vote to release log4net 2.0.14. Changelog is up

on

the

pre-release page at

https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1

I have updated staging docs and I _think_ I've done the right thing

with

respect to getting binaries and source up to the dev repo at
https://dist.apache.org/repos/dist/dev/logging, but the download

links

on

the staging docs point to the release download area, so I'm not sure

if

I

should rather upload there so that staging documentation "works as
expected" for the vote to continue.
Thanks Ralph for assisting me in being able to uplodate artifacts

myself.

Much appreciated.
-d
PS. This email is a duplicate of the one sent from my work email (
davyd.mcc...@codeo.co.za) which I believe has been lost somewhere

along the

way. Please ignore the other if it pops up.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing
Which is stupid.
- Alan Watts
https://www.youtube.com/watch?v=-gXTZM_uPMY
*Quidquid latine dictum sit, altum sonatur. *

--
Dominik Psenner

Re: [VOTE] Release log4net 2.0.14

[Davyd McColl]

Hi Matt, I'm happy to, just need to get the time to do the actually release 
(: holiday mode has kicked in good and proper. Can I close out before I 
release?


-d


On December 28, 2021 21:37:21 Matt Sicker  wrote:

Seems like we have enough votes to complete this release. Davyd, would you 
like to close the vote?

--
Matt Sicker


On Dec 25, 2021, at 14:50, Remko Popma  wrote:

+1

On Sat, Dec 25, 2021 at 6:35 AM Ralph Goers 
wrote:


+1

I checked the signature and hashes and those look good.

I unzipped the source and binaries. The appropriate license and notice
files are present.

I did not perform tests as I don’t have the necessary tools installed.

Ralph



On Dec 23, 2021, at 1:36 PM, Matt Sicker  wrote:

Root keys are in https://downloads.apache.org/logging/KEYS which is in
the dist repository where you commit releases.

On Mon, Dec 20, 2021 at 2:03 AM Dominik Psenner 

wrote:


* old-log4net.snk.gpg has been the old key to sign binaries.
* @Matt, where is the root logging KEYS file located?

The changes in the release look good to me. +1

On Mon, 20 Dec 2021 at 07:34, Davyd McColl  wrote:


Thanks Matt

Since you've given a +1, I'll write up some sticky notes to address

these

points in the near future.

-d


On December 19, 2021 23:51:45 Matt Sicker  wrote:


+1

Notes on the release:
* I’ve copied your release signing key to the root logging KEYS file

for

easier discoverability.
* The copyright year in the NOTICE file is a few years out of date at

this

point. I’ve updated this in master, though you’ll want to update this

again

in a couple weeks when it’s outdated again.
* Some included files in the base directory of the source zip are

missing

copyright headers or shouldn’t even be included in the tarball (e.g.,

the

appveyor config file probably isn’t necessary)
- Not sure what old-log4net.snk.gpg is in there for, either.
- Gulp task source files missing headers
* Artifact signatures and sha512 hashes look good (checked with shasum
which is the Perl script version), contain appropriate LICENSE and

NOTICE

(besides the outdated copyright year, but not a blocker), no binaries

in

the source zip, appropriate files in the binary zip.

--
Matt Sicker


On Dec 16, 2021, at 07:47, Davyd McColl  wrote:

Hi all

I'd like to raise a vote to release log4net 2.0.14. Changelog is up

on

the

pre-release page at


https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1


I have updated staging docs and I _think_ I've done the right thing

with

respect to getting binaries and source up to the dev repo at
https://dist.apache.org/repos/dist/dev/logging, but the download

links

on

the staging docs point to the release download area, so I'm not sure

if

I

should rather upload there so that staging documentation "works as
expected" for the vote to continue.

Thanks Ralph for assisting me in being able to uplodate artifacts

myself.

Much appreciated.

-d

PS. This email is a duplicate of the one sent from my work email (
davyd.mcc...@codeo.co.za) which I believe has been lost somewhere

along the

way. Please ignore the other if it pops up.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing

Which is stupid.

- Alan Watts
https://www.youtube.com/watch?v=-gXTZM_uPMY

*Quidquid latine dictum sit, altum sonatur. *







--
Dominik Psenner

Re: [VOTE] Release log4net 2.0.14

[Davyd McColl]

Thanks Matt

Since you've given a +1, I'll write up some sticky notes to address these 
points in the near future.


-d


On December 19, 2021 23:51:45 Matt Sicker  wrote:


+1

Notes on the release:
* I’ve copied your release signing key to the root logging KEYS file for 
easier discoverability.
* The copyright year in the NOTICE file is a few years out of date at this 
point. I’ve updated this in master, though you’ll want to update this again 
in a couple weeks when it’s outdated again.
* Some included files in the base directory of the source zip are missing 
copyright headers or shouldn’t even be included in the tarball (e.g., the 
appveyor config file probably isn’t necessary)

  - Not sure what old-log4net.snk.gpg is in there for, either.
  - Gulp task source files missing headers
* Artifact signatures and sha512 hashes look good (checked with shasum 
which is the Perl script version), contain appropriate LICENSE and NOTICE 
(besides the outdated copyright year, but not a blocker), no binaries in 
the source zip, appropriate files in the binary zip.


--
Matt Sicker


On Dec 16, 2021, at 07:47, Davyd McColl  wrote:

Hi all

I'd like to raise a vote to release log4net 2.0.14. Changelog is up on the
pre-release page at
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1

I have updated staging docs and I _think_ I've done the right thing with
respect to getting binaries and source up to the dev repo at
https://dist.apache.org/repos/dist/dev/logging, but the download links on
the staging docs point to the release download area, so I'm not sure if I
should rather upload there so that staging documentation "works as
expected" for the vote to continue.

Thanks Ralph for assisting me in being able to uplodate artifacts myself.
Much appreciated.

-d

PS. This email is a duplicate of the one sent from my work email (
davyd.mcc...@codeo.co.za) which I believe has been lost somewhere along the
way. Please ignore the other if it pops up.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing

Which is stupid.

- Alan Watts
https://www.youtube.com/watch?v=-gXTZM_uPMY

*Quidquid latine dictum sit, altum sonatur. *

Re: [VOTE] Release log4net 2.0.14

[Davyd McColl]

Hi Robert

I checked and saw the same sha discrepencies - the only reason I can think of 
is perhaps I interrupted a release script such that I had updated artifacts but 
interrupted before the shas were computed. Fixed-up now, thanks for the 
heads-up. Just to be sure, I've updated the release artifacts at GitHub too.

-d

On 2021-12-17 08:28:35, Davyd McColl  wrote:
Hi Robert
Binaries are signed with my key, though I remember someone raising that my key 
wasn't in a known area last time, so I'd appreciate help with that. I had a key 
signing party with Ralph and Matt quite a long time ago, but perhaps there's 
something I was supposed to do that I didn't ):
The sha mismatch is more concerning because the production of artifacts is 
automated from a script in the repo, so I'll need to go double-check what's 
going on there. Thanks for the heads-up though.
-d

On December 17, 2021 02:17:24 Robert Middleton  wrote:
I have updated staging docs and I _think_ I've done the right thing with
respect to getting binaries and source up to the dev repo at
https://dist.apache.org/repos/dist/dev/logging 
[https://dist.apache.org/repos/dist/dev/logging], but the download links on
the staging docs point to the release download area, so I'm not sure if I
should rather upload there so that staging documentation "works as
expected" for the vote to continue.


My understanding is that you don't upload to the release area until
the release is done.  Having the staging docs point at the release
area is fine to me at least(it's what I do for log4cxx), since that's
effectively a known issue with a release vote in my mind.
Anyway, I checked the binaries on
https://dist.apache.org/repos/dist/dev/logging 
[https://dist.apache.org/repos/dist/dev/logging], unfortunately it seems
as though there may be two problems:
1. SHA512 does not match the zip files at all
2. Signature doesn't seem to be valid, or I don't have the pubkey.
Which key is it signed with?
-Robert Middleton
On Thu, Dec 16, 2021 at 8:47 AM Davyd McColl  wrote:


Hi all
I'd like to raise a vote to release log4net 2.0.14. Changelog is up on the
pre-release page at
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1 
[https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1]
I have updated staging docs and I _think_ I've done the right thing with
respect to getting binaries and source up to the dev repo at
https://dist.apache.org/repos/dist/dev/logging 
[https://dist.apache.org/repos/dist/dev/logging], but the download links on
the staging docs point to the release download area, so I'm not sure if I
should rather upload there so that staging documentation "works as
expected" for the vote to continue.
Thanks Ralph for assisting me in being able to uplodate artifacts myself.
Much appreciated.
-d
PS. This email is a duplicate of the one sent from my work email (
davyd.mcc...@codeo.co.za) which I believe has been lost somewhere along the
way. Please ignore the other if it pops up.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing
Which is stupid.
- Alan Watts
https://www.youtube.com/watch?v=-gXTZM_uPMY 
[https://www.youtube.com/watch?v=-gXTZM_uPMY]
*Quidquid latine dictum sit, altum sonatur. *

Re: [VOTE] Release log4net 2.0.14

[Davyd McColl]

Hi Dominik

The staging site is updated. Really only release notes and download links 
changed - no api changes, so no sdk doc changes.


-d


On December 17, 2021 10:02:45 Dominik Psenner  wrote:


Hi Davyd,

I checked the changes since 2.0.13 and it looks good to me. Have you also
updated the log4net site? I would like to verify that the log4net website
looks good in staging.

Cheers
Dominik

On Thu, 16 Dec 2021 at 15:09, Davyd McColl 
wrote:


Hi all

I'd like to raise a vote to release log4net 2.0.14. Changelog is up on the
pre-release page at
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1

I have updated staging docs and I _think_ I've done the right thing with
respect to getting binaries and source up to the dev repo at
https://dist.apache.org/repos/dist/dev/logging, but the download links on
the staging docs point to the release download area, so I'm not sure if I
should rather upload there so that staging documentation "works as
expected" for the vote to continue.

Thanks Ralph for assisting me in being able to uplodate artifacts myself.
Much appreciated.

-d




--
Dominik Psenner

Re: [VOTE] Release log4net 2.0.14

[Davyd McColl]

Hi Robert

Binaries are signed with my key, though I remember someone raising that my 
key wasn't in a known area last time, so I'd appreciate help with that. I 
had a key signing party with Ralph and Matt quite a long time ago, but 
perhaps there's something I was supposed to do that I didn't ):
The sha mismatch is more concerning because the production of artifacts is 
automated from a script in the repo, so I'll need to go double-check what's 
going on there. Thanks for the heads-up though.


-d


On December 17, 2021 02:17:24 Robert Middleton  wrote:


I have updated staging docs and I _think_ I've done the right thing with
respect to getting binaries and source up to the dev repo at
https://dist.apache.org/repos/dist/dev/logging, but the download links on
the staging docs point to the release download area, so I'm not sure if I
should rather upload there so that staging documentation "works as
expected" for the vote to continue.


My understanding is that you don't upload to the release area until
the release is done.  Having the staging docs point at the release
area is fine to me at least(it's what I do for log4cxx), since that's
effectively a known issue with a release vote in my mind.

Anyway, I checked the binaries on
https://dist.apache.org/repos/dist/dev/logging, unfortunately it seems
as though there may be two problems:

1. SHA512 does not match the zip files at all
2. Signature doesn't seem to be valid, or I don't have the pubkey.
Which key is it signed with?

-Robert Middleton

On Thu, Dec 16, 2021 at 8:47 AM Davyd McColl  wrote:


Hi all

I'd like to raise a vote to release log4net 2.0.14. Changelog is up on the
pre-release page at
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1

I have updated staging docs and I _think_ I've done the right thing with
respect to getting binaries and source up to the dev repo at
https://dist.apache.org/repos/dist/dev/logging, but the download links on
the staging docs point to the release download area, so I'm not sure if I
should rather upload there so that staging documentation "works as
expected" for the vote to continue.

Thanks Ralph for assisting me in being able to uplodate artifacts myself.
Much appreciated.

-d

PS. This email is a duplicate of the one sent from my work email (
davyd.mcc...@codeo.co.za) which I believe has been lost somewhere along the
way. Please ignore the other if it pops up.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing

Which is stupid.

- Alan Watts
https://www.youtube.com/watch?v=-gXTZM_uPMY

*Quidquid latine dictum sit, altum sonatur. *

[VOTE] Release log4net 2.0.14

[Davyd McColl]

Hi all

I'd like to raise a vote to release log4net 2.0.14. Changelog is up on the 
pre-release page at 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1

I have updated staging docs and I _think_ I've done the right thing with 
respect to getting binaries and source up to the dev repo at 
https://dist.apache.org/repos/dist/dev/logging, but the download links on the 
staging docs point to the release download area, so I'm not sure if I should 
rather upload there so that staging documentation "works as expected" for the 
vote to continue.

Thanks Ralph for assisting me in being able to uplodate artifacts myself. Much 
appreciated.

-d

[VOTE] Release log4net 2.0.14

[Davyd McColl]

Hi all

I'd like to raise a vote to release log4net 2.0.14. Changelog is up on the
pre-release page at
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1

I have updated staging docs and I _think_ I've done the right thing with
respect to getting binaries and source up to the dev repo at
https://dist.apache.org/repos/dist/dev/logging, but the download links on
the staging docs point to the release download area, so I'm not sure if I
should rather upload there so that staging documentation "works as
expected" for the vote to continue.

Thanks Ralph for assisting me in being able to uplodate artifacts myself.
Much appreciated.

-d

PS. This email is a duplicate of the one sent from my work email (
davyd.mcc...@codeo.co.za) which I believe has been lost somewhere along the
way. Please ignore the other if it pops up.


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing

Which is stupid.

- Alan Watts
https://www.youtube.com/watch?v=-gXTZM_uPMY

*Quidquid latine dictum sit, altum sonatur. *

Re: log4net

[Davyd McColl]

Hi Joe

No, it shouldn't, particularly because we're very different projects, on 
very different platforms, and I understand that the log4j vuln is largely 
linked to a  _dependency_ of log4j. The closest we've had was an xml vuln 
that was patched some time ago.


That being said, I'm currently the only maintainer and I definitely have 
written the least code in log4net, so if you or anyone else would like to 
audit for vulnerabilities (and, even better, PR mitigations), I'm all for it.


-d


On December 14, 2021 16:03:39 Joe Kelly  wrote:

I was wondering if the log4net service has a similar vulnerability as 
log4j. There isn't any information on the log4net security page and the 
current version of 2.0.13 doesn't match the log4j version of 2.16.0.


Joe Kelly
Information Security Analyst
P: 405.763.5425
F: 405.602.6337
www.okcu.org

joe.ke...@okcu.org 
Oklahoma's Credit Union
Happy to Help(r)







NOTICE:
This e-mail is intended solely for the use of the individual to whom it is 
addressed and may contain information that is privileged, confidential or 
otherwise exempt from disclosure. If the reader of this e-mail is not the 
intended recipient or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this communication is strictly 
prohibited. If you have received this communication in error, please 
immediately notify us by replying to the original message at the listed 
email address.


Happy to Help
Oklahoma's Credit Union
http://www.okcu.org

Re: [Vote] Release log4net 2.0.13-rc2

[Davyd McColl]

Thanks Ralph, appreciated.

-d


On November 7, 2021 09:54:55 Ralph Goers  wrote:

I have committed the release files to 
https://dist.apache.org/repos/dist/release/logging/log4net/


Ralph


On Nov 2, 2021, at 8:56 AM, Davyd McColl  wrote:

Hi Ralph

Yes. I'd gladly upload them myself if I had permission to do so. If there's 
a way I can make it easier for you, please let me know.


:D


On November 2, 2021 17:27:12 Ralph Goers  wrote:


I have to manually download each one from the page?

Ralph


On Nov 2, 2021, at 12:13 AM, Davyd McColl  wrote:
Hi Ralph
There's an Assets section on the page at 
https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.13 - I 
think that download.apache.net just needs the binaries and source files? 
For each, there's a .zip, .asc and .sha512

-d
On 2021/11/02 08:35:07, Ralph Goers  wrote:
How do I download the files from there?
Ralph

On Nov 1, 2021, at 11:12 PM, Davyd McColl wrote:
Hi
Thanks all for the +1's; please can someone with access copy the binaries 
from the GitHub release (I've renamed to 
https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.13) to 
downloads.apache.org?

I'll be pushing to nuget shortly.
-d
On 2021/11/01 08:30:26, Ralph Goers wrote:
Everyone can vote - we encourage it. Only PMC members votes are “binding”. 
But PMC members take into account any concerns raised. And the vote tally 
will always include boih the binding and non-binding votes.

Ralph

On Oct 31, 2021, at 2:19 PM, David Schwartz wrote:
Not sure I qualify to vote, but looks good to me
+1
David Schwartz
Get Outlook for Android>

From: Ralph Goers >
Sent: Sunday, October 31, 2021 6:55:48 PM
To: dev@logging.apache.org >
Subject: [EXTERNAL] Re: [Vote] Release log4net 2.0.13-rc2
+1
Ralph

On Oct 31, 2021, at 5:52 AM, Robert Middleton wrote:
Looks good to me.
+1
-Robert Middleton
On Fri, Oct 29, 2021 at 6:08 PM Davyd McColl wrote:

Thank-you Remko
-d
Sent from Mailspring 
(https://urldefense.com/v3/__https://getmailspring.com/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgZQqMBGrA$ 
), the best free email app for work

On Oct 29 2021, at 11:04 pm, Remko Popma > wrote:

+1
On Sat, Oct 30, 2021 at 2:13 AM Davyd McColl >
wrote:

Hi
I'd like to raise a vote to release log4net 2.0.13 (this is an rc2 where
the only difference is the archive layout for the associated source and
binary artifacts)
- there's an rc up at GitHub with release notes:
https://urldefense.com/v3/__https://github.com/apache/logging-log4net/releases/tag/rc*2F2.0.13-rc2__;JQ!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgaXkcog4A$
- documentation is updated on staging:
https://urldefense.com/v3/__https://logging.staged.apache.org/log4net/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgan2OyPpw$ 
[
https://urldefense.com/v3/__https://logging.staged.apache.org/log4net/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgan2OyPpw$ 
]

I do, however, require some assistance with getting the artifacts from the
GitHub release page to download.apache.org - if I'm able to do so, I
don't know how, so any assistance is appreciated.
Once ratified, I will
- publish to nuget.org
- push documentation live
Thanks
-d

Re: Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Davyd McColl]

Hi

asf-staging branch merged into asf-site and I can see the latest release notes 
are up

Apologies again for missing this.

-d
On 2021/11/05 16:31:41, Davyd McColl  wrote:
Apologies - staging docs have not been set live ):

I'll have a look at it now

-d

On 2021/11/05 16:24:55, Volkan Yazıcı  wrote:
I think this message is best suited for this mailing list.
Would anybody from the log4net crew mind addressing the request of John
Bigler, please?

-- Forwarded message -
From: NuGet Gallery
Date: Thu, Nov 4, 2021 at 5:50 PM
Subject: [NuGet Gallery] Message for owners of the package 'log4net'
To:


*User JohnBig > sends the following
message to the owners of Package 'log4net 2.0.13
'.*

I see that version 2.0.13 was released around November 2, 2021, but does
not have any corresponding release notes on
https://logging.apache.org/log4net/release/release-notes.html. Would
someone from the development team be able to update those?

Kind regards,

John Bigler Pittsburgh, PA United States
--
* To stop receiving contact emails as an owner of this package, sign in to
the NuGet Gallery and change your email notification settings
. *


Privacy Statement
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA

Re: Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Davyd McColl]

Apologies - staging docs have not been set live ):

I'll have a look at it now

-d

On 2021/11/05 16:24:55, Volkan Yazıcı  wrote:
I think this message is best suited for this mailing list.
Would anybody from the log4net crew mind addressing the request of John
Bigler, please?

-- Forwarded message -
From: NuGet Gallery
Date: Thu, Nov 4, 2021 at 5:50 PM
Subject: [NuGet Gallery] Message for owners of the package 'log4net'
To:


*User JohnBig > sends the following
message to the owners of Package 'log4net 2.0.13
'.*

I see that version 2.0.13 was released around November 2, 2021, but does
not have any corresponding release notes on
https://logging.apache.org/log4net/release/release-notes.html. Would
someone from the development team be able to update those?

Kind regards,

John Bigler Pittsburgh, PA United States
--
* To stop receiving contact emails as an owner of this package, sign in to
the NuGet Gallery and change your email notification settings
. *


Privacy Statement
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA

Re: [Vote] Release log4net 2.0.13-rc2

[Davyd McColl]

Hi Ralph

Yes. I'd gladly upload them myself if I had permission to do so. If there's 
a way I can make it easier for you, please let me know.


:D


On November 2, 2021 17:27:12 Ralph Goers  wrote:


I have to manually download each one from the page?

Ralph


On Nov 2, 2021, at 12:13 AM, Davyd McColl  wrote:

Hi Ralph

There's an Assets section on the page at 
https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.13 - I 
think that download.apache.net just needs the binaries and source files? 
For each, there's a .zip, .asc and .sha512


-d
On 2021/11/02 08:35:07, Ralph Goers  wrote:
How do I download the files from there?

Ralph


On Nov 1, 2021, at 11:12 PM, Davyd McColl wrote:

Hi

Thanks all for the +1's; please can someone with access copy the binaries 
from the GitHub release (I've renamed to 
https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.13) to 
downloads.apache.org?


I'll be pushing to nuget shortly.

-d
On 2021/11/01 08:30:26, Ralph Goers wrote:
Everyone can vote - we encourage it. Only PMC members votes are “binding”. 
But PMC members take into account any concerns raised. And the vote tally 
will always include boih the binding and non-binding votes.


Ralph


On Oct 31, 2021, at 2:19 PM, David Schwartz wrote:

Not sure I qualify to vote, but looks good to me

+1

David Schwartz

Get Outlook for Android>

From: Ralph Goers >
Sent: Sunday, October 31, 2021 6:55:48 PM
To: dev@logging.apache.org >
Subject: [EXTERNAL] Re: [Vote] Release log4net 2.0.13-rc2

+1

Ralph


On Oct 31, 2021, at 5:52 AM, Robert Middleton wrote:

Looks good to me.

+1

-Robert Middleton

On Fri, Oct 29, 2021 at 6:08 PM Davyd McColl wrote:


Thank-you Remko

-d
Sent from Mailspring 
(https://urldefense.com/v3/__https://getmailspring.com/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgZQqMBGrA$ 
), the best free email app for work

On Oct 29 2021, at 11:04 pm, Remko Popma > wrote:

+1

On Sat, Oct 30, 2021 at 2:13 AM Davyd McColl >
wrote:


Hi

I'd like to raise a vote to release log4net 2.0.13 (this is an rc2 where
the only difference is the archive layout for the associated source and
binary artifacts)

- there's an rc up at GitHub with release notes:
https://urldefense.com/v3/__https://github.com/apache/logging-log4net/releases/tag/rc*2F2.0.13-rc2__;JQ!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgaXkcog4A$
- documentation is updated on staging:
https://urldefense.com/v3/__https://logging.staged.apache.org/log4net/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgan2OyPpw$ 
[
https://urldefense.com/v3/__https://logging.staged.apache.org/log4net/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgan2OyPpw$ 
]


I do, however, require some assistance with getting the artifacts from the
GitHub release page to download.apache.org - if I'm able to do so, I
don't know how, so any assistance is appreciated.

Once ratified, I will
- publish to nuget.org
- push documentation live

Thanks
-d

Re: [Vote] Release log4net 2.0.13-rc2

[Davyd McColl]

Hi Ralph

There's an Assets section on the page at 
https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.13 - I think 
that download.apache.net just needs the binaries and source files? For each, 
there's a .zip, .asc and .sha512

-d
On 2021/11/02 08:35:07, Ralph Goers  wrote:
How do I download the files from there?

Ralph

> On Nov 1, 2021, at 11:12 PM, Davyd McColl wrote:
>
> Hi
>
> Thanks all for the +1's; please can someone with access copy the binaries 
> from the GitHub release (I've renamed to 
> https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.13) to 
> downloads.apache.org?
>
> I'll be pushing to nuget shortly.
>
> -d
> On 2021/11/01 08:30:26, Ralph Goers wrote:
> Everyone can vote - we encourage it. Only PMC members votes are “binding”. 
> But PMC members take into account any concerns raised. And the vote tally 
> will always include boih the binding and non-binding votes.
>
> Ralph
>
>> On Oct 31, 2021, at 2:19 PM, David Schwartz wrote:
>>
>> Not sure I qualify to vote, but looks good to me
>>
>> +1
>>
>> David Schwartz
>>
>> Get Outlook for Android>
>> 
>> From: Ralph Goers >
>> Sent: Sunday, October 31, 2021 6:55:48 PM
>> To: dev@logging.apache.org >
>> Subject: [EXTERNAL] Re: [Vote] Release log4net 2.0.13-rc2
>>
>> +1
>>
>> Ralph
>>
>>> On Oct 31, 2021, at 5:52 AM, Robert Middleton wrote:
>>>
>>> Looks good to me.
>>>
>>> +1
>>>
>>> -Robert Middleton
>>>
>>> On Fri, Oct 29, 2021 at 6:08 PM Davyd McColl wrote:
>>>>
>>>> Thank-you Remko
>>>>
>>>> -d
>>>> Sent from Mailspring 
>>>> (https://urldefense.com/v3/__https://getmailspring.com/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgZQqMBGrA$
>>>>  ), the best free email app for work
>>>> On Oct 29 2021, at 11:04 pm, Remko Popma > wrote:
>>>>> +1
>>>>>
>>>>> On Sat, Oct 30, 2021 at 2:13 AM Davyd McColl >
>>>>> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I'd like to raise a vote to release log4net 2.0.13 (this is an rc2 where
>>>>>> the only difference is the archive layout for the associated source and
>>>>>> binary artifacts)
>>>>>>
>>>>>> - there's an rc up at GitHub with release notes:
>>>>>> https://urldefense.com/v3/__https://github.com/apache/logging-log4net/releases/tag/rc*2F2.0.13-rc2__;JQ!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgaXkcog4A$
>>>>>> - documentation is updated on staging:
>>>>>> https://urldefense.com/v3/__https://logging.staged.apache.org/log4net/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgan2OyPpw$
>>>>>>  [
>>>>>> https://urldefense.com/v3/__https://logging.staged.apache.org/log4net/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgan2OyPpw$
>>>>>>  ]
>>>>>>
>>>>>> I do, however, require some assistance with getting the artifacts from 
>>>>>> the
>>>>>> GitHub release page to download.apache.org - if I'm able to do so, I
>>>>>> don't know how, so any assistance is appreciated.
>>>>>>
>>>>>> Once ratified, I will
>>>>>> - publish to nuget.org
>>>>>> - push documentation live
>>>>>>
>>>>>> Thanks
>>>>>> -d
>

Re: [Vote] Release log4net 2.0.13-rc2

[Davyd McColl]

Hi again

2.0.13 is up on nuget, so the only missing piece of the puzzle is the build 
artifacts to be up on download.apache.org, whenever someone has a gap to assist.

Thanks for the vote (:

-d
On 2021/11/02 08:13:08, Davyd McColl  wrote:
Hi

Thanks all for the +1's; please can someone with access copy the binaries from 
the GitHub release (I've renamed to 
https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.13) to 
downloads.apache.org?

I'll be pushing to nuget shortly.

-d
On 2021/11/01 08:30:26, Ralph Goers  wrote:
Everyone can vote - we encourage it. Only PMC members votes are “binding”. But 
PMC members take into account any concerns raised. And the vote tally will 
always include boih the binding and non-binding votes.

Ralph

> On Oct 31, 2021, at 2:19 PM, David Schwartz wrote:
>
> Not sure I qualify to vote, but looks good to me
>
> +1
>
> David Schwartz
>
> Get Outlook for Android>
> 
> From: Ralph Goers >
> Sent: Sunday, October 31, 2021 6:55:48 PM
> To: dev@logging.apache.org >
> Subject: [EXTERNAL] Re: [Vote] Release log4net 2.0.13-rc2
>
> +1
>
> Ralph
>
>> On Oct 31, 2021, at 5:52 AM, Robert Middleton wrote:
>>
>> Looks good to me.
>>
>> +1
>>
>> -Robert Middleton
>>
>> On Fri, Oct 29, 2021 at 6:08 PM Davyd McColl wrote:
>>>
>>> Thank-you Remko
>>>
>>> -d
>>> Sent from Mailspring 
>>> (https://urldefense.com/v3/__https://getmailspring.com/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgZQqMBGrA$
>>>  ), the best free email app for work
>>> On Oct 29 2021, at 11:04 pm, Remko Popma > wrote:
>>>> +1
>>>>
>>>> On Sat, Oct 30, 2021 at 2:13 AM Davyd McColl >
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I'd like to raise a vote to release log4net 2.0.13 (this is an rc2 where
>>>>> the only difference is the archive layout for the associated source and
>>>>> binary artifacts)
>>>>>
>>>>> - there's an rc up at GitHub with release notes:
>>>>> https://urldefense.com/v3/__https://github.com/apache/logging-log4net/releases/tag/rc*2F2.0.13-rc2__;JQ!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgaXkcog4A$
>>>>> - documentation is updated on staging:
>>>>> https://urldefense.com/v3/__https://logging.staged.apache.org/log4net/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgan2OyPpw$
>>>>>  [
>>>>> https://urldefense.com/v3/__https://logging.staged.apache.org/log4net/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgan2OyPpw$
>>>>>  ]
>>>>>
>>>>> I do, however, require some assistance with getting the artifacts from the
>>>>> GitHub release page to download.apache.org - if I'm able to do so, I
>>>>> don't know how, so any assistance is appreciated.
>>>>>
>>>>> Once ratified, I will
>>>>> - publish to nuget.org
>>>>> - push documentation live
>>>>>
>>>>> Thanks
>>>>> -d

Re: [Vote] Release log4net 2.0.13-rc2

[Davyd McColl]

Hi

Thanks all for the +1's; please can someone with access copy the binaries from 
the GitHub release (I've renamed to 
https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.13) to 
downloads.apache.org?

I'll be pushing to nuget shortly.

-d
On 2021/11/01 08:30:26, Ralph Goers  wrote:
Everyone can vote - we encourage it. Only PMC members votes are “binding”. But 
PMC members take into account any concerns raised. And the vote tally will 
always include boih the binding and non-binding votes.

Ralph

> On Oct 31, 2021, at 2:19 PM, David Schwartz wrote:
>
> Not sure I qualify to vote, but looks good to me
>
> +1
>
> David Schwartz
>
> Get Outlook for Android>
> 
> From: Ralph Goers >
> Sent: Sunday, October 31, 2021 6:55:48 PM
> To: dev@logging.apache.org >
> Subject: [EXTERNAL] Re: [Vote] Release log4net 2.0.13-rc2
>
> +1
>
> Ralph
>
>> On Oct 31, 2021, at 5:52 AM, Robert Middleton wrote:
>>
>> Looks good to me.
>>
>> +1
>>
>> -Robert Middleton
>>
>> On Fri, Oct 29, 2021 at 6:08 PM Davyd McColl wrote:
>>>
>>> Thank-you Remko
>>>
>>> -d
>>> Sent from Mailspring 
>>> (https://urldefense.com/v3/__https://getmailspring.com/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgZQqMBGrA$
>>>  ), the best free email app for work
>>> On Oct 29 2021, at 11:04 pm, Remko Popma > wrote:
>>>> +1
>>>>
>>>> On Sat, Oct 30, 2021 at 2:13 AM Davyd McColl >
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I'd like to raise a vote to release log4net 2.0.13 (this is an rc2 where
>>>>> the only difference is the archive layout for the associated source and
>>>>> binary artifacts)
>>>>>
>>>>> - there's an rc up at GitHub with release notes:
>>>>> https://urldefense.com/v3/__https://github.com/apache/logging-log4net/releases/tag/rc*2F2.0.13-rc2__;JQ!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgaXkcog4A$
>>>>> - documentation is updated on staging:
>>>>> https://urldefense.com/v3/__https://logging.staged.apache.org/log4net/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgan2OyPpw$
>>>>>  [
>>>>> https://urldefense.com/v3/__https://logging.staged.apache.org/log4net/__;!!FbZ0ZwI3Qg!6mWLEkOJqhEMiM1iwaou5mdmqxCnY_vuSu3n-U-_XVC4VFuRE4yZgAd6zgan2OyPpw$
>>>>>  ]
>>>>>
>>>>> I do, however, require some assistance with getting the artifacts from the
>>>>> GitHub release page to download.apache.org - if I'm able to do so, I
>>>>> don't know how, so any assistance is appreciated.
>>>>>
>>>>> Once ratified, I will
>>>>> - publish to nuget.org
>>>>> - push documentation live
>>>>>
>>>>> Thanks
>>>>> -d

Re: [Vote] Release log4net 2.0.13-rc2

[Davyd McColl]

Thank-you Remko

-d
Sent from Mailspring (https://getmailspring.com/), the best free email app for 
work
On Oct 29 2021, at 11:04 pm, Remko Popma  wrote:
> +1
>
> On Sat, Oct 30, 2021 at 2:13 AM Davyd McColl 
> wrote:
>
> > Hi
> >
> > I'd like to raise a vote to release log4net 2.0.13 (this is an rc2 where
> > the only difference is the archive layout for the associated source and
> > binary artifacts)
> >
> > - there's an rc up at GitHub with release notes:
> > https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.13-rc2
> > - documentation is updated on staging:
> > https://logging.staged.apache.org/log4net/ [
> > https://logging.staged.apache.org/log4net/]
> >
> > I do, however, require some assistance with getting the artifacts from the
> > GitHub release page to download.apache.org - if I'm able to do so, I
> > don't know how, so any assistance is appreciated.
> >
> > Once ratified, I will
> > - publish to nuget.org
> > - push documentation live
> >
> > Thanks
> > -d
> >
>

[Vote] Release log4net 2.0.13-rc2

[Davyd McColl]

Hi

I'd like to raise a vote to release log4net 2.0.13 (this is an rc2 where the 
only difference is the archive layout for the associated source and binary 
artifacts)

- there's an rc up at GitHub with release notes: 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.13-rc2
- documentation is updated on staging: 
https://logging.staged.apache.org/log4net/ 
[https://logging.staged.apache.org/log4net/]

I do, however, require some assistance with getting the artifacts from the 
GitHub release page to download.apache.org - if I'm able to do so, I don't know 
how, so any assistance is appreciated.

Once ratified, I will
- publish to nuget.org
- push documentation live

Thanks
-d

Re: [VOTE] Release log4net 2.0.13

[Davyd McColl]

Thanks Matt

I'm cancelling this vote in deference to the new one.

-d


On October 29, 2021 17:21:09 Matt Sicker  wrote:

Just reply to the old vote thread with a message saying you’re cancelling 
the vote.



On Oct 29, 2021, at 9:29 AM, Davyd McColl  wrote:

Hi Ralph

I'm not sure how to cancel, other than saying here - it's cancelled? I'll 
raise a new vote now with updated links.


-d
On 2021/10/29 16:28:15, Ralph Goers  wrote:
You really should cancel the first vote and start a new one. Please 
reference the RC candidate number in the subject. I apologize for not 
replying earlier.


Ralph


On Oct 28, 2021, at 12:48 AM, Davyd McColl wrote:

Update: I've added a 2.0.13 RC2 release at GitHub with the suggested 
modifications to release artifacts (source and binary zips). The released 
functionality remains unchanged.


-d
On 2021/10/28 08:49:23, Davyd McColl wrote:
Hi Robert

Thanks for checking all these things and feeding back to me
1. SDK reference: I've linked in the older reference now, since the sdk 
hasn't changed, but this reminds me that I wanted to add building this to 
the release pipeline, and hadn't yet found a good generator - I'll put this 
on my TODO for the next time
2. I'll look into if I can pipe files into a container folder in the zip 
file (I'm using gulp-zip). If it's not a blocker, I can make this a TODO 
for next time
3. I'm not sure how to get my key into that file - I remember a signing 
party very long ago with Ralph and Matt and I don't know if there's 
something I need to do?


Thanks
-d
On 2021/10/28 00:12:18, Robert Middleton wrote:
Two non-blocking notes:
- The 'SDK Reference' link on the staged site is a 404, I'm not sure
if that's intentional or not:
https://logging.staged.apache.org/log4net/release/sdk/index.html
- For the zip files, it would probably be good to put everything in a
top-level folder and then zip that folder
up(apache-log4net-source-2.0.13). Extracting the zips would
potentially pollute your current directory, which may be unexpected.

Your key doesn't seem to be in the KEYS file for logging, so I can't
check that: https://www.apache.org/dist/logging/KEYS

-Robert Middleton




On Wed, Oct 27, 2021 at 2:10 AM Davyd McColl
wrote:


Hi

I'd like to raise a vote to release log4net 2.0.13

- there's an rc up at GitHub with release notes: 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.13
- documentation is updated on staging: 
https://logging.staged.apache.org/log4net/


I do, however, require some assistance with getting the artifacts from the 
GitHub release page to download.apache.org - if I'm able to do so, I don't 
know how, so any assistance is appreciated.


Once ratified, I will
- publish to nuget.org
- push documentation live

Thanks
-d

Re: [VOTE] Release log4net 2.0.13

[Davyd McColl]

Hi Ralph

I'm not sure how to cancel, other than saying here - it's cancelled? I'll raise 
a new vote now with updated links.

-d
On 2021/10/29 16:28:15, Ralph Goers  wrote:
You really should cancel the first vote and start a new one. Please reference 
the RC candidate number in the subject. I apologize for not replying earlier.

Ralph

> On Oct 28, 2021, at 12:48 AM, Davyd McColl wrote:
>
> Update: I've added a 2.0.13 RC2 release at GitHub with the suggested 
> modifications to release artifacts (source and binary zips). The released 
> functionality remains unchanged.
>
> -d
> On 2021/10/28 08:49:23, Davyd McColl wrote:
> Hi Robert
>
> Thanks for checking all these things and feeding back to me
> 1. SDK reference: I've linked in the older reference now, since the sdk 
> hasn't changed, but this reminds me that I wanted to add building this to the 
> release pipeline, and hadn't yet found a good generator - I'll put this on my 
> TODO for the next time
> 2. I'll look into if I can pipe files into a container folder in the zip file 
> (I'm using gulp-zip). If it's not a blocker, I can make this a TODO for next 
> time
> 3. I'm not sure how to get my key into that file - I remember a signing party 
> very long ago with Ralph and Matt and I don't know if there's something I 
> need to do?
>
> Thanks
> -d
> On 2021/10/28 00:12:18, Robert Middleton wrote:
> Two non-blocking notes:
> - The 'SDK Reference' link on the staged site is a 404, I'm not sure
> if that's intentional or not:
> https://logging.staged.apache.org/log4net/release/sdk/index.html
> - For the zip files, it would probably be good to put everything in a
> top-level folder and then zip that folder
> up(apache-log4net-source-2.0.13). Extracting the zips would
> potentially pollute your current directory, which may be unexpected.
>
> Your key doesn't seem to be in the KEYS file for logging, so I can't
> check that: https://www.apache.org/dist/logging/KEYS
>
> -Robert Middleton
>
>
>
>
> On Wed, Oct 27, 2021 at 2:10 AM Davyd McColl
> wrote:
>>
>> Hi
>>
>> I'd like to raise a vote to release log4net 2.0.13
>>
>> - there's an rc up at GitHub with release notes: 
>> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.13
>> - documentation is updated on staging: 
>> https://logging.staged.apache.org/log4net/
>>
>> I do, however, require some assistance with getting the artifacts from the 
>> GitHub release page to download.apache.org - if I'm able to do so, I don't 
>> know how, so any assistance is appreciated.
>>
>> Once ratified, I will
>> - publish to nuget.org
>> - push documentation live
>>
>> Thanks
>> -d

Re: [VOTE] Release log4net 2.0.13

[Davyd McColl]

Update: I've added a 2.0.13 RC2 release at GitHub with the suggested 
modifications to release artifacts (source and binary zips). The released 
functionality remains unchanged.

-d
On 2021/10/28 08:49:23, Davyd McColl  wrote:
Hi Robert

Thanks for checking all these things and feeding back to me
1. SDK reference: I've linked in the older reference now, since the sdk hasn't 
changed, but this reminds me that I wanted to add building this to the release 
pipeline, and hadn't yet found a good generator - I'll put this on my TODO for 
the next time
2. I'll look into if I can pipe files into a container folder in the zip file 
(I'm using gulp-zip). If it's not a blocker, I can make this a TODO for next 
time
3. I'm not sure how to get my key into that file - I remember a signing party 
very long ago with Ralph and Matt and I don't know if there's something I need 
to do?

Thanks
-d
On 2021/10/28 00:12:18, Robert Middleton  wrote:
Two non-blocking notes:
- The 'SDK Reference' link on the staged site is a 404, I'm not sure
if that's intentional or not:
https://logging.staged.apache.org/log4net/release/sdk/index.html
- For the zip files, it would probably be good to put everything in a
top-level folder and then zip that folder
up(apache-log4net-source-2.0.13). Extracting the zips would
potentially pollute your current directory, which may be unexpected.

Your key doesn't seem to be in the KEYS file for logging, so I can't
check that: https://www.apache.org/dist/logging/KEYS

-Robert Middleton




On Wed, Oct 27, 2021 at 2:10 AM Davyd McColl
wrote:
>
> Hi
>
> I'd like to raise a vote to release log4net 2.0.13
>
> - there's an rc up at GitHub with release notes: 
> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.13
> - documentation is updated on staging: 
> https://logging.staged.apache.org/log4net/
>
> I do, however, require some assistance with getting the artifacts from the 
> GitHub release page to download.apache.org - if I'm able to do so, I don't 
> know how, so any assistance is appreciated.
>
> Once ratified, I will
> - publish to nuget.org
> - push documentation live
>
> Thanks
> -d

Re: [VOTE] Release log4net 2.0.13

[Davyd McColl]

Hi Robert

Thanks for checking all these things and feeding back to me
1. SDK reference: I've linked in the older reference now, since the sdk hasn't 
changed, but this reminds me that I wanted to add building this to the release 
pipeline, and hadn't yet found a good generator - I'll put this on my TODO for 
the next time
2. I'll look into if I can pipe files into a container folder in the zip file 
(I'm using gulp-zip). If it's not a blocker, I can make this a TODO for next 
time
3. I'm not sure how to get my key into that file - I remember a signing party 
very long ago with Ralph and Matt and I don't know if there's something I need 
to do?

Thanks
-d
On 2021/10/28 00:12:18, Robert Middleton  wrote:
Two non-blocking notes:
- The 'SDK Reference' link on the staged site is a 404, I'm not sure
if that's intentional or not:
https://logging.staged.apache.org/log4net/release/sdk/index.html
- For the zip files, it would probably be good to put everything in a
top-level folder and then zip that folder
up(apache-log4net-source-2.0.13). Extracting the zips would
potentially pollute your current directory, which may be unexpected.

Your key doesn't seem to be in the KEYS file for logging, so I can't
check that: https://www.apache.org/dist/logging/KEYS

-Robert Middleton




On Wed, Oct 27, 2021 at 2:10 AM Davyd McColl
wrote:
>
> Hi
>
> I'd like to raise a vote to release log4net 2.0.13
>
> - there's an rc up at GitHub with release notes: 
> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.13
> - documentation is updated on staging: 
> https://logging.staged.apache.org/log4net/
>
> I do, however, require some assistance with getting the artifacts from the 
> GitHub release page to download.apache.org - if I'm able to do so, I don't 
> know how, so any assistance is appreciated.
>
> Once ratified, I will
> - publish to nuget.org
> - push documentation live
>
> Thanks
> -d

[VOTE] Release log4net 2.0.13

[Davyd McColl]

Hi

I'd like to raise a vote to release log4net 2.0.13

- there's an rc up at GitHub with release notes: 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.13
- documentation is updated on staging: 
https://logging.staged.apache.org/log4net/

I do, however, require some assistance with getting the artifacts from the 
GitHub release page to download.apache.org - if I'm able to do so, I don't know 
how, so any assistance is appreciated.

Once ratified, I will
- publish to nuget.org
- push documentation live

Thanks
-d

RE: Re: Fix for Issue Log4net-611

[Davyd McColl]

Hi David

I've incorporated your changes and a few other small changes from PRs which 
were open and active up at GitHub. I've prepared release artifacts and reached 
out to Ralph for some help as it's been a very long time (entirely my fault) 
since I was active on the project. Once I've been able to upload the staging 
doc site and signed artifacts, I'll open a vote on this mailing list and 
subject to that passing, do a proper release on nuget.org.

In the mean-time, there's an rc release up at 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.13 if you'd 
like to test against your own system.

-d
On 2021/10/24 18:35:33, David Schwartz  wrote:
Hi David,

Thanks a million for taking a look.

I am sure there is little I can do to help it get released, but just in case, I 
will offer. Let me know if there is anything I can do to help the new version 
get released. In fact, let me know if there is anything I can do for log4net in 
general. Always wanted to be part of an open source project in a more real way.

Thanks

David

-----Original Message-
From: Davyd McColl
Sent: Sunday, October 24, 2021 4:07 PM
To: dev@logging.apache.org
Subject: [EXTERNAL] Re: Fix for Issue Log4net-611

Hi

I'll try get some time to look at this this week. There's another small fix I'd 
like to make and I've been putting it off because the release process is such a 
mission (the apache way of doing things - unlike my libraries which I can just 
release, log4net has to go through a vote and republish docs and so forth, even 
though I'm the only one maintaining it right now.

Thanks for the pr - I'll try check it out tomorrow.

-d


On October 24, 2021 11:29:52 David Schwartz wrote:

> Hi Log4Net,
>
> I have a PR to repair issue 611 for .netstandard 2.0 libraries.
>
> https://urldefense.com/v3/__https://issues.apache.org/jira/browse/LOG4
> NET-611__;!!FbZ0ZwI3Qg!5_XHxKYCPk2rnYryApcLEuBiFixyCfmAw-Q0KQ3iIJKxLhw
> a48wrMiwtrN2rVY7j_g$
>
> It is a small change to the AssemblyInfo.cs to allow low trust level
> for .netstandard 2.0 compilation (which is already the setting for
> netframework
> 4.7.2)
>
> https://urldefense.com/v3/__https://github.com/apache/logging-log4net/
> pull/76__;!!FbZ0ZwI3Qg!5_XHxKYCPk2rnYryApcLEuBiFixyCfmAw-Q0KQ3iIJKxLhw
> a48wrMiwtrN3QAWnZ-g$
>
> I need this as part of the migration plan of our products to .net
> standard / .net 5. Could someone please review/approve the PR and
> then release a new version of log4net with this change?
>
> Thank you
>
> David Schwartz
> NI

Re: Fix for Issue Log4net-611

[Davyd McColl]

Hi

I'll try get some time to look at this this week. There's another small fix 
I'd like to make and I've been putting it off because the release process 
is such a mission (the apache way of doing things - unlike my libraries 
which I can just release, log4net has to go through a vote and republish 
docs and so forth, even though I'm the only one maintaining it right now.


Thanks for the pr - I'll try check it out tomorrow.

-d


On October 24, 2021 11:29:52 David Schwartz  wrote:


Hi Log4Net,

I have a PR to repair issue 611 for .netstandard 2.0 libraries.

https://issues.apache.org/jira/browse/LOG4NET-611

It is a small change to the AssemblyInfo.cs to allow low trust level for 
.netstandard 2.0 compilation (which is already the setting for netframework 
4.7.2)


https://github.com/apache/logging-log4net/pull/76

I need this as part of the migration plan of our products to .net standard 
/ .net 5.  Could someone please review/approve the PR and then release a 
new version of log4net with this change?


Thank you

David Schwartz
NI

Re: Log4Go

[Davyd McColl]

Hi Ralph

I can't create a repo under the apache org on GitHub. I'm also perhaps not the 
best person to start off the project - I'm still very new to Go, having only 
worked a bit in it - learned enough to have had two PRs accepted to lazygit 
(https://github.com/jesseduffield/lazygit) and I'm not sure of the 
generally-accepted defaults / layout / structures for go projects. When I 
raised my paw, it was largely because I'd like to learn from people who do have 
this kind of experience (: I've found that working on lazygit has made me learn 
more than following a course, not in the least because there's existing code 
and structure there and people to tell me when I Do It Wrong :D

I'm still very happy to be involved in log4go (assuming it's called that).

-d
On 2021/07/01 17:23:40, Ralph Goers  wrote:
Davyd,

You have commit rights but I am not sure if that gives you the ability to 
create a new repo. But before doing that I would create a confluence page to 
lay out the initial requirements and design.

If you can’t create a repo and would like one I can certainly help with that.

Ralph

> On Jun 30, 2021, at 12:44 PM, Davyd McColl wrote:
>
> I'm rather new to go, but looking for ways to improve by writing code 
> alongside people who actually know what they're doing. If I can help, please 
> ping me.
>
> -d
>
>
> On June 30, 2021 18:12:46 Christofer Dutz wrote:
>
>> Hi all,
>>
>> and sorry for being late to the party ;-)
>>
>> I am currently working hard on PLC4X' Go support and am also using what I 
>> create in the Open-Source project in some larger corporate applications.
>>
>> One thing that has always bugged me with go, was the inavailability of 
>> loggers that allow me to set different log levels for different parts of the 
>> application. In go with every half-efficient logging framework, it's an all 
>> or nothing thing. So if I want to track down a problem in my driver for 
>> protocol X and I switch logging to TRACE it's like trying to drink out of an 
>> open fire-hose.
>>
>> What I would love to do as a first step, and I don't think it should be too 
>> complicated, would be to create a Go API that allows us to define 
>> hierarchies of log levels, just like we know them in the Java world. This 
>> API would be used in the application to log, but it wouldn't actually do any 
>> logging but internally sort of use an underlying framework (possibly auto 
>> configured to TRACE or the most talkative log level) and forward log 
>> requests to that if it passes the filter criteria.
>>
>> So in PLC4Go for example we could use this Go Logging API. If my company now 
>> uses logrus or zerolog, then all we have to do in that application is 
>> initialize the log4go system (I know there's a project using that name 
>> pattern ... I'm referring to something we built) with the corresponding 
>> adapter.
>>
>> What do you think? I'm not one of these "I whish someone would build X for 
>> me" folks ... I am willing to put quite some effort into something like 
>> this. But I think it should be in a project like Apache Logging and not as a 
>> side project of PLC4X.
>>
>> Chris
>>
>>
>> On 2020/12/11 12:20:18 Volkan Yazıcı wrote:
>>> I support the initiative. At bol.com, we also needed to implement our own
>>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
>>> and I don't think I will be able to spare time to both learn a new language
>>> (even though I am really into learning Go) and maintain such a project. I
>>> mean, not that you need my help, but just wanted to share my availability.
>>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
>>> I also agree with Matt that this would pave the road to standardizing the
>>> logging configuration file formats across multiple languages.
>>> What I witness most for code — in particular libraries, APIs, etc. —
>>> written by programmers whose expertise is actually in another language,
>>> that they mostly don't get the language conventions right. For instance, I
>>> was horrified many times in the past to read/use Java code written by
>>> JavaScript (front-end) developers. These two languages have totally
>>> different approaches and (community embraced) conventions that one cannot
>>> plug-n-play the mindset of one to another. In conclusion, as far as I know,
>>> none of us is programming in Go on a daily basis. Hence, I strongly
>>> recommend consulting to experts in this domain be

Re: Re: Log4Go

[Davyd McColl]

I'm rather new to go, but looking for ways to improve by writing code 
alongside people who actually know what they're doing. If I can help, 
please ping me.


-d


On June 30, 2021 18:12:46 Christofer Dutz  wrote:


Hi all,

and sorry for being late to the party ;-)

I am currently working hard on PLC4X' Go support and am also using what I 
create in the Open-Source project in some larger corporate applications.


One thing that has always bugged me with go, was the inavailability of 
loggers that allow me to set different log levels for different parts of 
the application. In go with every half-efficient logging framework, it's an 
all or nothing thing. So if I want to track down a problem in my driver for 
protocol X and I switch logging to TRACE it's like trying to drink out of 
an open fire-hose.


What I would love to do as a first step, and I don't think it should be too 
complicated, would be to create a Go API that allows us to define 
hierarchies of log levels, just like we know them in the Java world. This 
API would be used in the application to log, but it wouldn't actually do 
any logging but internally sort of use an underlying framework (possibly 
auto configured to TRACE or the most talkative log level) and forward log 
requests to that if it passes the filter criteria.


So in PLC4Go for example we could use this Go Logging API. If my company 
now uses logrus or zerolog, then all we have to do in that application is 
initialize the log4go system (I know there's a project using that name 
pattern ... I'm referring to something we built) with the corresponding 
adapter.


What do you think? I'm not one of these "I whish someone would build X for 
me" folks ... I am willing to put quite some effort into something like 
this. But I think it should be in a project like Apache Logging and not as 
a side project of PLC4X.


Chris


On 2020/12/11 12:20:18 Volkan Yazıcı wrote:

I support the initiative. At bol.com, we also needed to implement our own
Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go
and I don't think I will be able to spare time to both learn a new language
(even though I am really into learning Go) and maintain such a project. I
mean, not that you need my help, but just wanted to share my availability.
If I would have time, I would rather clean up Log4j bugs piled up in JIRA.

I also agree with Matt that this would pave the road to standardizing the
logging configuration file formats across multiple languages.

What I witness most for code — in particular libraries, APIs, etc. —
written by programmers whose expertise is actually in another language,
that they mostly don't get the language conventions right. For instance, I
was horrified many times in the past to read/use Java code written by
JavaScript (front-end) developers. These two languages have totally
different approaches and (community embraced) conventions that one cannot
plug-n-play the mindset of one to another. In conclusion, as far as I know,
none of us is programming in Go on a daily basis. Hence, I strongly
recommend consulting to experts in this domain before publishing something
to the outside world. For one, I am pretty sure there should be Go experts
within the Apache community, hence having expert reviews should be
relatively easy. Second, Apache has such a good track record in delivering
high quality software, even an inferior project might get quite some
attraction and we will be bound to maintain it for years. These are my
concerns in general. That said, I would be more than happy to ditch off our
custom Go loggers with an Apache-approved alternative.

On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers 
wrote:

> The company I work for has started using Go for some of the middleware
> components we are developing. I have looked at several logging frameworks
> for Go and have not been impressed by any of them. As such, I am
> considering starting a project here. The major goals of this would be:
>
> Use an external configuration (at least JSON and XML).
> Allow the configuration to be accessed via HTTP(S) - Spring Cloud
> Configuration.
> Allow dynamic reconfiguration.
> Allow plugins (probably as Go plugins?)
> Support for Markers, context attributes, Layouts, Appenders.
>
> Anyone interested?
>
> Ralph
>
>

Re: [meta] What's been going on with log4net, log4cxx, and chainsaw? Request for reports

[Davyd McColl]

Hi Matt

log4net has been quite quiet over the last quarter, partly because I took a 
break from all things code for a month, and partly because I'm still trying to 
pick up momentum after that break!

However, there has been minor movement at GitHub, and your mail has reminded me 
to get back on track with chipping away at the JIRA board.

-d
On 2021/02/09 19:40:43, Matt Sicker  wrote:
Over the past year or two, I've been working to include more details
in our quarterly board report about what's been going on in the
community and development. As I'm mostly active in Log4j and some
adjacent code, I'm not always very informed about the development
details in log4net, log4cxx, and chainsaw. While I do try to review
the PRs, emails, and Jira issues that had activity during each
quarter, as I'm not deep in the weeds of those subprojects, I haven't
been able to do them justice in our past reports, especially as these
subprojects experienced new bursts of activity.

Past board reports from this PMC are at [1] which dates back to the
founding of the project. Interestingly enough, this lack of detailed
reporting for non-log4j subprojects here has been a theme since
forever. I'd love to improve on this by emulating what the Apache
Incubator does by having our subprojects individually report summaries
of their past quarter to the PMC. Then we can report and publish
richer and more detailed summaries of what's going on.

We have a board report due this week, so I don't really expect that we
can fully bootstrap this idea for that one. Our next board report will
be due in early May 2021, so subproject summaries should be assembled
by the end of April 2021. Would anyone like to volunteer to shepherd
or write up summaries for any particular subproject here? We
particularly need people to help report on the projects mentioned in
the subject.

[1]: https://whimsy.apache.org/board/minutes/Logging_Services.html

Re: [LOG4NET] Vote for release: 2.0.12

[Davyd McColl]

Thanks Ralph

-d


On October 26, 2020 18:48:30 Ralph Goers  wrote:


The files were added to the distribution directory.

Ralph


On Oct 26, 2020, at 9:22 AM, Ralph Goers  wrote:

OK

+1 to these.

Ralph


On Oct 26, 2020, at 8:57 AM, Davyd McColl  wrote:

Ralph, here's the 2.0.12 thread where Matt and Remko voted.

-d


On October 23, 2020 17:57:31 Davyd McColl  wrote:


Thanks Matt

I think I need 3 to release... Any other takers?

-d


On October 23, 2020 17:33:19 Matt Sicker  wrote:


It seems I forgot to add my +1 here.

On Mon, 19 Oct 2020 at 01:45, Davyd McColl  wrote:


Hi Remko

Yes, this is a vote thread -- thanks for your +1 (:

Matt, I've fortunately found that the maintainer of gulp-zip did a minor
release which sorts out the issue -- I was behind by one minor and the code
that I saw, _not_ setting mode on folders is the fix... I've updated the
release at
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12 and have
tested the source zip.

Thanks
-d

On 2020/10/19 08:25:06, Remko Popma  wrote:
Is this not a vote thread?




On Oct 19, 2020, at 13:27, Matt Sicker wrote:

Interesting. Anyways, as there are workarounds, it’s not a release blocker
at least.


On Sun, Oct 18, 2020 at 23:14 Davyd McColl wrote:

Hi Matt

Looks like the culprit is gulp-zip, specifically, the source I see sets
mode for files but not folders (with a source comment about why and a link
to some other issue). Since there are people with issues open since 2016
and I don't see a way to change this behavior with arguments, this looks
like yet another npm module I'll have to fork and maintain myself (or copy,
embed and fix in log4net, at the very least). May take me a little while.

-d


On October 18, 2020 22:24:41 Matt Sicker wrote:

I've tried extracting it via unzip, tar, and the built in macOS GUI
unzipper, and all three respect the permissions specified which cause
permissions errors on unix. Being that this release is to help fix
something for non-windows users, it'll be hard for them to use any of
the artifacts besides the nupkg (which is likely the more frequently
used artifact I'd imagine). Doing a zipinfo on the nupkg file notes
that it's encoded using zip 2.0 in fat permissions format while the
source and binary zips are encoded from zip 6.3 in unix permissions
format.

What you might want to figure out is how to make the win32 zippers
_not_ add unix permissions since they're doing it wrong. :)


On Sun, 18 Oct 2020 at 13:55, Davyd McColl wrote:




Hi Matt

Zip files are created from windows as there are certain targets that
Unix compiles can't hit (specifically < net40 and client profiles), which
would probably explain the permissions. Not a lot I can do about it

though,

that I know of. If it's an issue and someone knows how to convince win32
zippers to do Unix permissions, I'm all ears.

-d

On October 18, 2020 20:07:18 Matt Sicker wrote:



Signatures and checksums are good. Once I extracted the zips, though,
I see they have some strange permissions configured. All the
directories have a chmod of rw-rw-rw (just like all the files do), but
they should be rwxr-xr-x. Example output from zipinfo comparing
log4net zip with log4j zip:

Archive: apache-log4j-2.13.3-bin.zip
Zip file size: 14581816 bytes, number of entries: 74
drwxr-xr-x 2.0 unx 0 b- stor 20-May-10 12:06
apache-log4j-2.13.3-bin/
-rw-r--r-- 2.0 unx 2888 bl defN 20-May-10 11:56
apache-log4j-2.13.3-bin/RELEASE-NOTES.md
...

Archive: apache-log4net-binaries-2.0.12.zip
Zip file size: 2154452 bytes, number of entries: 28
drw-rw-rw- 6.3 unx 0 b- stor 20-Oct-18 17:22 net20/
...
-rw-rw-rw- 6.3 unx 262144 b- defN 20-Oct-18 17:22 net20/log4net.dll
...

The directories need to be executable to be able to list files from
them (Unix/POSIX). I'm not sure how these zip files got these
permissions. I see that the previous 2.0.10 release of log4net has the
same problem, though.

On Sun, 18 Oct 2020 at 11:03, Davyd McColl wrote:


Hi all

Not much has changed in 2.0.12 except that an issue affecting
non-windows users has been addressed. LOG4NET-652 and LOG4NET-653

both stem

from the same source, wherein the username for the current logging

thread

was not correctly retrieved on non-windows platforms and would throw a
PlatformNotSupported error. I was hoping that one of the authors of pull
requests to resolve this would respond to my comments on said pull
requests, but it's been a while now and there's been a user asking

when the

update would be released, so, as much as I would have liked the

community

member commits, I've gone ahead and applied the logic myself.

Anyways, 2.0.12 is up for release at
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12 [
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12]

with signed artifacts there. Documentation is updated at the staging

site

-- all that's left is a sanity check and vote

[Announce] [log4net] release 2.0.12

[Davyd McColl]

Hi all

I'd like to announce the release of log4net 2.0.12, which resolves issues 
LOG4NET-652 AND LOG4NET-653, both of which are related to correctly 
retrieving the username for the current thread, which would throw an 
exception on non-win32 platforms.


The site is up, nupkg is released, please can a member push artifacts the 
last mile to apache download servers. GitHub release is here: 
https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.12


Thanks
-d

Re: [LOG4NET] Vote for release: 2.0.12

[Davyd McColl]

Ralph, here's the 2.0.12 thread where Matt and Remko voted.

-d


On October 23, 2020 17:57:31 Davyd McColl  wrote:


Thanks Matt

I think I need 3 to release... Any other takers?

-d


On October 23, 2020 17:33:19 Matt Sicker  wrote:


It seems I forgot to add my +1 here.

On Mon, 19 Oct 2020 at 01:45, Davyd McColl  wrote:


Hi Remko

Yes, this is a vote thread -- thanks for your +1 (:

Matt, I've fortunately found that the maintainer of gulp-zip did a minor
release which sorts out the issue -- I was behind by one minor and the code
that I saw, _not_ setting mode on folders is the fix... I've updated the
release at
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12 and have
tested the source zip.

Thanks
-d

On 2020/10/19 08:25:06, Remko Popma  wrote:
Is this not a vote thread?



> On Oct 19, 2020, at 13:27, Matt Sicker wrote:
>
> Interesting. Anyways, as there are workarounds, it’s not a release blocker
> at least.
>
>> On Sun, Oct 18, 2020 at 23:14 Davyd McColl wrote:
>>
>> Hi Matt
>>
>> Looks like the culprit is gulp-zip, specifically, the source I see sets
>> mode for files but not folders (with a source comment about why and a link
>> to some other issue). Since there are people with issues open since 2016
>> and I don't see a way to change this behavior with arguments, this looks
>> like yet another npm module I'll have to fork and maintain myself (or copy,
>> embed and fix in log4net, at the very least). May take me a little while.
>>
>> -d
>>
>>> On October 18, 2020 22:24:41 Matt Sicker wrote:
>>>
>>> I've tried extracting it via unzip, tar, and the built in macOS GUI
>>> unzipper, and all three respect the permissions specified which cause
>>> permissions errors on unix. Being that this release is to help fix
>>> something for non-windows users, it'll be hard for them to use any of
>>> the artifacts besides the nupkg (which is likely the more frequently
>>> used artifact I'd imagine). Doing a zipinfo on the nupkg file notes
>>> that it's encoded using zip 2.0 in fat permissions format while the
>>> source and binary zips are encoded from zip 6.3 in unix permissions
>>> format.
>>>
>>> What you might want to figure out is how to make the win32 zippers
>>> _not_ add unix permissions since they're doing it wrong. :)
>>>
>>>> On Sun, 18 Oct 2020 at 13:55, Davyd McColl wrote:
>>>
>>>>
>>>> Hi Matt
>>>>
>>>> Zip files are created from windows as there are certain targets that
>>>> Unix compiles can't hit (specifically < net40 and client profiles), which
>>>> would probably explain the permissions. Not a lot I can do about it
though,
>>>> that I know of. If it's an issue and someone knows how to convince win32
>>>> zippers to do Unix permissions, I'm all ears.
>>>>
>>>> -d
>>>>
>>>> On October 18, 2020 20:07:18 Matt Sicker wrote:
>>>>
>>>>>
>>>>> Signatures and checksums are good. Once I extracted the zips, though,
>>>>> I see they have some strange permissions configured. All the
>>>>> directories have a chmod of rw-rw-rw (just like all the files do), but
>>>>> they should be rwxr-xr-x. Example output from zipinfo comparing
>>>>> log4net zip with log4j zip:
>>>>>
>>>>> Archive: apache-log4j-2.13.3-bin.zip
>>>>> Zip file size: 14581816 bytes, number of entries: 74
>>>>> drwxr-xr-x 2.0 unx 0 b- stor 20-May-10 12:06
>>>>> apache-log4j-2.13.3-bin/
>>>>> -rw-r--r-- 2.0 unx 2888 bl defN 20-May-10 11:56
>>>>> apache-log4j-2.13.3-bin/RELEASE-NOTES.md
>>>>> ...
>>>>>
>>>>> Archive: apache-log4net-binaries-2.0.12.zip
>>>>> Zip file size: 2154452 bytes, number of entries: 28
>>>>> drw-rw-rw- 6.3 unx 0 b- stor 20-Oct-18 17:22 net20/
>>>>> ...
>>>>> -rw-rw-rw- 6.3 unx 262144 b- defN 20-Oct-18 17:22 net20/log4net.dll
>>>>> ...
>>>>>
>>>>> The directories need to be executable to be able to list files from
>>>>> them (Unix/POSIX). I'm not sure how these zip files got these
>>>>> permissions. I see that the previous 2.0.10 release of log4net has the
>>>>> same problem, though.
>>>>>
>>>>> On Sun, 18 Oct 2020 at 11:03, Davyd McColl wrote:
>>>>>
>>>>>> Hi all
>>>>&

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Ralph, I think this thread has been a little confused along the way -- I see 
that the title of this mail includes the version 2.0.11, but the current 
release is 2.0.12, which includes the versioning fix mentioned in this thread, 
as well as fixes for LOG4NET-(652|653) wherein the username associated with the 
current thread was not being properly handled on non-win32 targets (and was, in 
fact, throwing an exception). I'm not entirely sure when the confusion settled 
in, but the initial vote was set off on Friday 23 October, and was voted +1 by 
both Remko and Matt, however your response has been to this thread, so I'd like 
to double-check whether your vote is for the 2.0.12 release? I know the cat's 
kinda out the proverbial bag... however, before I go declaring that I have 3 
votes on 2.0.12, I'd like to make sure!

I swear, one of these days I'm going to do a release without a hiccup :|

-d

On 2020/10/26 16:35:46, Davyd McColl  wrote:
Hi Matt

Thanks, I still forget some of the dots and crosses ):

-d

On 2020/10/26 16:20:58, Matt Sicker  wrote:
Yes, an email confirming the vote passed along with the tally. Then,
after everything has been uploaded and mirrored, we can send an
announcement email about the release.

On Mon, 26 Oct 2020 at 06:58, Davyd McColl wrote:
>
> By results, I understand you mean a tally? There were only three votes, all
> positive. I've pushed the nupkg.
>
> -d
>
>
> On October 26, 2020 13:35:15 Apache wrote:
>
> > You need to close the vote thread with the results first before performing
> > the final release steps.
> >
> > Ralph
> >
> >> On Oct 25, 2020, at 11:24 PM, Davyd McColl wrote:
> >>
> >> Thanks Ralph
> >>
> >> Could you assist with getting artifacts up to downloads.apache.org? I'm
> >> going to push the nupkg because people are waiting on it, and will have to
> >> set the new documentation live because people will expect it, but right
> >> now, the download links are broken.
> >>
> >> Thanks
> >> -d
> >>
> >> On 2020/10/25 01:21:15, Ralph Goers wrote:
> >> My +1
> >>
> >> Ralph
> >>
> >>> On Sep 22, 2020, at 11:21 PM, Davyd McColl wrote:
> >>>
> >>> Thanks all; I've completed the release as far as I can (Ralph, please push
> >>> the relevant artifacts from
> >>> https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.11 the
> >>> last mile) and pushed the nuget package.
> >>>
> >>> -d
> >>>
> >>> On 2020/09/22 17:34:34, Matt Sicker wrote:
> >>> +1
> >>>
> >>>> On Tue, Sep 22, 2020 at 04:23 Dominik Psenner wrote:
> >>>>
> >>>> +1
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Sent from my phone. Typos are a kind gift to anyone who happens to find
> >>>>
> >>>> them.
> >>>>
> >>>>
> >>>>
> >>>>> On Tue, Sep 22, 2020, 08:37 Davyd McColl wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Hi all
> >>>>
> >>>>>
> >>>>
> >>>>> I'd appreciate any more +1's (thanks, Remko!). I'd like to get this out
> >>>>
> >>>>> the door because it fixes confusing versioning on the released binaries
> >>>> (in
> >>>>
> >>>>> particular, nuget consumers)
> >>>>
> >>>>>
> >>>>
> >>>>> Thanks
> >>>>
> >>>>> -d
> >>>>
> >>>>>> On 2020/09/20 22:33:49, Matt Sicker wrote:
> >>>>
> >>>>> I can use whatever.
> >>>>
> >>>>>
> >>>>
> >>>>>> On Sun, 20 Sep 2020 at 15:26, Ralph Goers wrote:
> >>>>
> >>>>>>
> >>>>
> >>>>>> I don’t have google meet and I can’t use Skype since Microsoft hosed my
> >>>>
> >>>>> authentication. I have zoom. My company uses Amazon Chime, which is
> >>>> fairly
> >>>>
> >>>>> new, as part of our product offering. I’ve sent you both emails for a
> >>>>
> >>>>> meeting using that.
> >>>>
> >>>>>>
> >>>>
> >>>>>> Ralph
> >>>>
> >>>>>>

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Hi Matt

Thanks, I still forget some of the dots and crosses ):

-d

On 2020/10/26 16:20:58, Matt Sicker  wrote:
Yes, an email confirming the vote passed along with the tally. Then,
after everything has been uploaded and mirrored, we can send an
announcement email about the release.

On Mon, 26 Oct 2020 at 06:58, Davyd McColl wrote:
>
> By results, I understand you mean a tally? There were only three votes, all
> positive. I've pushed the nupkg.
>
> -d
>
>
> On October 26, 2020 13:35:15 Apache wrote:
>
> > You need to close the vote thread with the results first before performing
> > the final release steps.
> >
> > Ralph
> >
> >> On Oct 25, 2020, at 11:24 PM, Davyd McColl wrote:
> >>
> >> Thanks Ralph
> >>
> >> Could you assist with getting artifacts up to downloads.apache.org? I'm
> >> going to push the nupkg because people are waiting on it, and will have to
> >> set the new documentation live because people will expect it, but right
> >> now, the download links are broken.
> >>
> >> Thanks
> >> -d
> >>
> >> On 2020/10/25 01:21:15, Ralph Goers wrote:
> >> My +1
> >>
> >> Ralph
> >>
> >>> On Sep 22, 2020, at 11:21 PM, Davyd McColl wrote:
> >>>
> >>> Thanks all; I've completed the release as far as I can (Ralph, please push
> >>> the relevant artifacts from
> >>> https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.11 the
> >>> last mile) and pushed the nuget package.
> >>>
> >>> -d
> >>>
> >>> On 2020/09/22 17:34:34, Matt Sicker wrote:
> >>> +1
> >>>
> >>>> On Tue, Sep 22, 2020 at 04:23 Dominik Psenner wrote:
> >>>>
> >>>> +1
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Sent from my phone. Typos are a kind gift to anyone who happens to find
> >>>>
> >>>> them.
> >>>>
> >>>>
> >>>>
> >>>>> On Tue, Sep 22, 2020, 08:37 Davyd McColl wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Hi all
> >>>>
> >>>>>
> >>>>
> >>>>> I'd appreciate any more +1's (thanks, Remko!). I'd like to get this out
> >>>>
> >>>>> the door because it fixes confusing versioning on the released binaries
> >>>> (in
> >>>>
> >>>>> particular, nuget consumers)
> >>>>
> >>>>>
> >>>>
> >>>>> Thanks
> >>>>
> >>>>> -d
> >>>>
> >>>>>> On 2020/09/20 22:33:49, Matt Sicker wrote:
> >>>>
> >>>>> I can use whatever.
> >>>>
> >>>>>
> >>>>
> >>>>>> On Sun, 20 Sep 2020 at 15:26, Ralph Goers wrote:
> >>>>
> >>>>>>
> >>>>
> >>>>>> I don’t have google meet and I can’t use Skype since Microsoft hosed my
> >>>>
> >>>>> authentication. I have zoom. My company uses Amazon Chime, which is
> >>>> fairly
> >>>>
> >>>>> new, as part of our product offering. I’ve sent you both emails for a
> >>>>
> >>>>> meeting using that.
> >>>>
> >>>>>>
> >>>>
> >>>>>> Ralph
> >>>>
> >>>>>>
> >>>>
> >>>>>>>> On Sep 20, 2020, at 1:01 PM, Matt Sicker wrote:
> >>>>
> >>>>>>>
> >>>>
> >>>>>>> I sent a Google Meet invite to you.
> >>>>
> >>>>>>>
> >>>>
> >>>>>>>> On Sun, 20 Sep 2020 at 14:26, Davyd McColl wrote:
> >>>>
> >>>>>>>>
> >>>>
> >>>>>>>> I'm happy to be available at 8am my side, if that works for everyone
> >>>>
> >>>>> else.
> >>>>
> >>>>>>>> It sounds like earlier would be better, but I'm doing the morning
> >>>>
> >>>>> school
> >>>>
> >>>>>>>> run from 7am and can't guarantee I'll be b

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

By results, I understand you mean a tally? There were only three votes, all 
positive. I've pushed the nupkg.


-d


On October 26, 2020 13:35:15 Apache  wrote:

You need to close the vote thread with the results first before performing 
the final release steps.


Ralph


On Oct 25, 2020, at 11:24 PM, Davyd McColl  wrote:

Thanks Ralph

Could you assist with getting artifacts up to downloads.apache.org? I'm 
going to push the nupkg because people are waiting on it, and will have to 
set the new documentation live because people will expect it, but right 
now, the download links are broken.


Thanks
-d

On 2020/10/25 01:21:15, Ralph Goers  wrote:
My +1

Ralph


On Sep 22, 2020, at 11:21 PM, Davyd McColl wrote:

Thanks all; I've completed the release as far as I can (Ralph, please push 
the relevant artifacts from 
https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.11 the 
last mile) and pushed the nuget package.


-d

On 2020/09/22 17:34:34, Matt Sicker wrote:
+1


On Tue, Sep 22, 2020 at 04:23 Dominik Psenner wrote:

+1



--

Sent from my phone. Typos are a kind gift to anyone who happens to find

them.




On Tue, Sep 22, 2020, 08:37 Davyd McColl wrote:





Hi all







I'd appreciate any more +1's (thanks, Remko!). I'd like to get this out



the door because it fixes confusing versioning on the released binaries

(in


particular, nuget consumers)







Thanks



-d



On 2020/09/20 22:33:49, Matt Sicker wrote:



I can use whatever.







On Sun, 20 Sep 2020 at 15:26, Ralph Goers wrote:







I don’t have google meet and I can’t use Skype since Microsoft hosed my



authentication. I have zoom. My company uses Amazon Chime, which is

fairly


new, as part of our product offering. I’ve sent you both emails for a



meeting using that.







Ralph







On Sep 20, 2020, at 1:01 PM, Matt Sicker wrote:







I sent a Google Meet invite to you.







On Sun, 20 Sep 2020 at 14:26, Davyd McColl wrote:







I'm happy to be available at 8am my side, if that works for everyone



else.



It sounds like earlier would be better, but I'm doing the morning



school



run from 7am and can't guarantee I'll be back significantly before



8am.







How to do this? I have zoom and slack on my work machine, can

install


Skype if that's more convenient, can do google meet, I assume,

though


haven't ever tried, so may need a bit of a crash intro.







If posting meeting details to the mailing list is not on, feel free

to


email me directly (:







-d











On September 20, 2020 20:58:29 Ralph Goers wrote:







8am in Durban South Africa is 11pm the night before in Phoenix AZ.



However, I frequently am up until midnight so that could work.



5-5:30 pm is



7:30-8 am in Phoenix. I usually am not in front of my computer on a



weekday



until 8 am but on occasion I can do earlier.







Ralph







On Sep 20, 2020, at 9:46 AM, Davyd McColl wrote:







Any time 08h00 - 17h30 utc+2, except 13h00-14h00 (that's when I



fetch my



son from school)







-d











On September 20, 2020 18:44:19 Matt Sicker wrote:







We’re not quite as strict as Debian for keys (though if you can



find a



Debian group locally, they’re great for key signing). The video



call idea



could work for exchanging keys. What times would you be available



to do



that?







On Sun, Sep 20, 2020 at 03:09 Davyd McColl wrote:







Hi Ralph















I think I miscommunicated: I'm not regenerating my signing key -



just the







nuget API key for package upload. This forces me to log in in



nuget.org







which has 2fa and then I only use that key on the cli for the



immediate



upload.















My gpg key as at https://GitHub.com/fluffynuts.gpg is the same



that I



used







last time.















-d























On September 20, 2020 09:01:36 Ralph Goers



wrote:















In the long run you don’t want to be regenerating your signing



key for







every release. The point is that you would upload the key to a



central







keystore and other people would sign it there. At ApacheCon we



would



have a







key signing “party” where we recorded each others keys and then



would



take







our list and update the central keystore. When people verify

the


key



they







can look at the keystore and see that it is signed by a number

of


people,







who then have their keys by a number of people and so on so you



are







building a web of trust. Sooner or later there will be someone



in that



web







that you personally know and trust.















Ralph















On Sep 19, 2020, at 11:26 PM, Davyd McColl wrote:















Thanks Matt, I've updated the artifacts on GitHub to have



detached







signatures. I had previously also uploaded my key to



sks-keyservers.net,











but I've also uploa

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Thanks Ralph

Could you assist with getting artifacts up to downloads.apache.org? I'm going 
to push the nupkg because people are waiting on it, and will have to set the 
new documentation live because people will expect it, but right now, the 
download links are broken.

Thanks
-d

On 2020/10/25 01:21:15, Ralph Goers  wrote:
My +1

Ralph

> On Sep 22, 2020, at 11:21 PM, Davyd McColl wrote:
>
> Thanks all; I've completed the release as far as I can (Ralph, please push 
> the relevant artifacts from 
> https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.11 the last 
> mile) and pushed the nuget package.
>
> -d
>
> On 2020/09/22 17:34:34, Matt Sicker wrote:
> +1
>
> On Tue, Sep 22, 2020 at 04:23 Dominik Psenner wrote:
>
>> +1
>>
>>
>>
>> --
>>
>> Sent from my phone. Typos are a kind gift to anyone who happens to find
>>
>> them.
>>
>>
>>
>> On Tue, Sep 22, 2020, 08:37 Davyd McColl wrote:
>>
>>
>>
>>> Hi all
>>
>>>
>>
>>> I'd appreciate any more +1's (thanks, Remko!). I'd like to get this out
>>
>>> the door because it fixes confusing versioning on the released binaries
>> (in
>>
>>> particular, nuget consumers)
>>
>>>
>>
>>> Thanks
>>
>>> -d
>>
>>> On 2020/09/20 22:33:49, Matt Sicker wrote:
>>
>>> I can use whatever.
>>
>>>
>>
>>> On Sun, 20 Sep 2020 at 15:26, Ralph Goers wrote:
>>
>>>>
>>
>>>> I don’t have google meet and I can’t use Skype since Microsoft hosed my
>>
>>> authentication. I have zoom. My company uses Amazon Chime, which is
>> fairly
>>
>>> new, as part of our product offering. I’ve sent you both emails for a
>>
>>> meeting using that.
>>
>>>>
>>
>>>> Ralph
>>
>>>>
>>
>>>>> On Sep 20, 2020, at 1:01 PM, Matt Sicker wrote:
>>
>>>>>
>>
>>>>> I sent a Google Meet invite to you.
>>
>>>>>
>>
>>>>> On Sun, 20 Sep 2020 at 14:26, Davyd McColl wrote:
>>
>>>>>>
>>
>>>>>> I'm happy to be available at 8am my side, if that works for everyone
>>
>>> else.
>>
>>>>>> It sounds like earlier would be better, but I'm doing the morning
>>
>>> school
>>
>>>>>> run from 7am and can't guarantee I'll be back significantly before
>>
>>> 8am.
>>
>>>>>>
>>
>>>>>> How to do this? I have zoom and slack on my work machine, can
>> install
>>
>>>>>> Skype if that's more convenient, can do google meet, I assume,
>> though
>>
>>>>>> haven't ever tried, so may need a bit of a crash intro.
>>
>>>>>>
>>
>>>>>> If posting meeting details to the mailing list is not on, feel free
>> to
>>
>>>>>> email me directly (:
>>
>>>>>>
>>
>>>>>> -d
>>
>>>>>>
>>
>>>>>>
>>
>>>>>> On September 20, 2020 20:58:29 Ralph Goers wrote:
>>
>>>>>>
>>
>>>>>>> 8am in Durban South Africa is 11pm the night before in Phoenix AZ.
>>
>>>>>>> However, I frequently am up until midnight so that could work.
>>
>>> 5-5:30 pm is
>>
>>>>>>> 7:30-8 am in Phoenix. I usually am not in front of my computer on a
>>
>>> weekday
>>
>>>>>>> until 8 am but on occasion I can do earlier.
>>
>>>>>>>
>>
>>>>>>> Ralph
>>
>>>>>>>
>>
>>>>>>>> On Sep 20, 2020, at 9:46 AM, Davyd McColl wrote:
>>
>>>>>>>>
>>
>>>>>>>> Any time 08h00 - 17h30 utc+2, except 13h00-14h00 (that's when I
>>
>>> fetch my
>>
>>>>>>>> son from school)
>>
>>>>>>>>
>>
>>>>>>>> -d
>>
>>>>>>>>
>>
>>>>>>>>
>>
>>>>>>>> On September 20, 2020 18:44:19 Matt Sicker wrote:
>>
>>>>>>>>
>>
>>>>>>>>> We’re not quite as strict as Debian for keys (though if you can
>>
>&g

Re: Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Davyd McColl]

Hi Dominik

iirc, this was fixed in 2.0.11. 2.0.12, with another fix for current user 
name on !win32, is waiting on one more +1 vote for release.


-d


On October 23, 2020 18:05:18 Dominik Psenner  wrote:


See the message below.
--
Sent from my phone.

-- Forwarded message -
From: NuGet Gallery 
Date: Fri, Oct 23, 2020, 07:51
Subject: [NuGet Gallery] Message for owners of the package 'log4net'
To: 


*User santoshkallatti > sends the following message to
the owners of Package 'log4net 2.0.10
'.*

Hi,

There is an assembly version mismatch in log4net 2.0.10. The assembly's
manifest definition contains 'log4net, Version=2.0.9.0'. May I know why
this version mismatch. Can I get log4net 2.0.10 nuget package with manifest
definition contains 'log4net, Version=2.0.10.0'?

Thanks & Regards Santosh K
--
* To stop receiving contact emails as an owner of this package, sign in to
the NuGet Gallery and change your email notification settings
. *


Privacy Statement 
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA

Re: [LOG4NET] Vote for release: 2.0.12

[Davyd McColl]

Thanks Matt

I think I need 3 to release... Any other takers?

-d


On October 23, 2020 17:33:19 Matt Sicker  wrote:


It seems I forgot to add my +1 here.

On Mon, 19 Oct 2020 at 01:45, Davyd McColl  wrote:


Hi Remko

Yes, this is a vote thread -- thanks for your +1 (:

Matt, I've fortunately found that the maintainer of gulp-zip did a minor 
release which sorts out the issue -- I was behind by one minor and the code 
that I saw, _not_ setting mode on folders is the fix... I've updated the 
release at 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12 and have 
tested the source zip.


Thanks
-d

On 2020/10/19 08:25:06, Remko Popma  wrote:
Is this not a vote thread?



> On Oct 19, 2020, at 13:27, Matt Sicker wrote:
>
> Interesting. Anyways, as there are workarounds, it’s not a release blocker
> at least.
>
>> On Sun, Oct 18, 2020 at 23:14 Davyd McColl wrote:
>>
>> Hi Matt
>>
>> Looks like the culprit is gulp-zip, specifically, the source I see sets
>> mode for files but not folders (with a source comment about why and a link
>> to some other issue). Since there are people with issues open since 2016
>> and I don't see a way to change this behavior with arguments, this looks
>> like yet another npm module I'll have to fork and maintain myself (or copy,
>> embed and fix in log4net, at the very least). May take me a little while.
>>
>> -d
>>
>>> On October 18, 2020 22:24:41 Matt Sicker wrote:
>>>
>>> I've tried extracting it via unzip, tar, and the built in macOS GUI
>>> unzipper, and all three respect the permissions specified which cause
>>> permissions errors on unix. Being that this release is to help fix
>>> something for non-windows users, it'll be hard for them to use any of
>>> the artifacts besides the nupkg (which is likely the more frequently
>>> used artifact I'd imagine). Doing a zipinfo on the nupkg file notes
>>> that it's encoded using zip 2.0 in fat permissions format while the
>>> source and binary zips are encoded from zip 6.3 in unix permissions
>>> format.
>>>
>>> What you might want to figure out is how to make the win32 zippers
>>> _not_ add unix permissions since they're doing it wrong. :)
>>>
>>>> On Sun, 18 Oct 2020 at 13:55, Davyd McColl wrote:
>>>
>>>>
>>>> Hi Matt
>>>>
>>>> Zip files are created from windows as there are certain targets that
>>>> Unix compiles can't hit (specifically < net40 and client profiles), which
>>>> would probably explain the permissions. Not a lot I can do about it 
though,

>>>> that I know of. If it's an issue and someone knows how to convince win32
>>>> zippers to do Unix permissions, I'm all ears.
>>>>
>>>> -d
>>>>
>>>> On October 18, 2020 20:07:18 Matt Sicker wrote:
>>>>
>>>>>
>>>>> Signatures and checksums are good. Once I extracted the zips, though,
>>>>> I see they have some strange permissions configured. All the
>>>>> directories have a chmod of rw-rw-rw (just like all the files do), but
>>>>> they should be rwxr-xr-x. Example output from zipinfo comparing
>>>>> log4net zip with log4j zip:
>>>>>
>>>>> Archive: apache-log4j-2.13.3-bin.zip
>>>>> Zip file size: 14581816 bytes, number of entries: 74
>>>>> drwxr-xr-x 2.0 unx 0 b- stor 20-May-10 12:06
>>>>> apache-log4j-2.13.3-bin/
>>>>> -rw-r--r-- 2.0 unx 2888 bl defN 20-May-10 11:56
>>>>> apache-log4j-2.13.3-bin/RELEASE-NOTES.md
>>>>> ...
>>>>>
>>>>> Archive: apache-log4net-binaries-2.0.12.zip
>>>>> Zip file size: 2154452 bytes, number of entries: 28
>>>>> drw-rw-rw- 6.3 unx 0 b- stor 20-Oct-18 17:22 net20/
>>>>> ...
>>>>> -rw-rw-rw- 6.3 unx 262144 b- defN 20-Oct-18 17:22 net20/log4net.dll
>>>>> ...
>>>>>
>>>>> The directories need to be executable to be able to list files from
>>>>> them (Unix/POSIX). I'm not sure how these zip files got these
>>>>> permissions. I see that the previous 2.0.10 release of log4net has the
>>>>> same problem, though.
>>>>>
>>>>> On Sun, 18 Oct 2020 at 11:03, Davyd McColl wrote:
>>>>>
>>>>>> Hi all
>>>>>>
>>>>>> Not much has changed in 2.0.12 except that an issue affecting
>>>>>> non-

Re: [LOG4NET] Vote for release: 2.0.12

[Davyd McColl]

Hi Remko

Yes, this is a vote thread -- thanks for your +1 (:

Matt, I've fortunately found that the maintainer of gulp-zip did a minor 
release which sorts out the issue -- I was behind by one minor and the code 
that I saw, _not_ setting mode on folders is the fix... I've updated the 
release at https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12 
and have tested the source zip.

Thanks
-d

On 2020/10/19 08:25:06, Remko Popma  wrote:
Is this not a vote thread?



> On Oct 19, 2020, at 13:27, Matt Sicker wrote:
>
> Interesting. Anyways, as there are workarounds, it’s not a release blocker
> at least.
>
>> On Sun, Oct 18, 2020 at 23:14 Davyd McColl wrote:
>>
>> Hi Matt
>>
>> Looks like the culprit is gulp-zip, specifically, the source I see sets
>> mode for files but not folders (with a source comment about why and a link
>> to some other issue). Since there are people with issues open since 2016
>> and I don't see a way to change this behavior with arguments, this looks
>> like yet another npm module I'll have to fork and maintain myself (or copy,
>> embed and fix in log4net, at the very least). May take me a little while.
>>
>> -d
>>
>>> On October 18, 2020 22:24:41 Matt Sicker wrote:
>>>
>>> I've tried extracting it via unzip, tar, and the built in macOS GUI
>>> unzipper, and all three respect the permissions specified which cause
>>> permissions errors on unix. Being that this release is to help fix
>>> something for non-windows users, it'll be hard for them to use any of
>>> the artifacts besides the nupkg (which is likely the more frequently
>>> used artifact I'd imagine). Doing a zipinfo on the nupkg file notes
>>> that it's encoded using zip 2.0 in fat permissions format while the
>>> source and binary zips are encoded from zip 6.3 in unix permissions
>>> format.
>>>
>>> What you might want to figure out is how to make the win32 zippers
>>> _not_ add unix permissions since they're doing it wrong. :)
>>>
>>>> On Sun, 18 Oct 2020 at 13:55, Davyd McColl wrote:
>>>
>>>>
>>>> Hi Matt
>>>>
>>>> Zip files are created from windows as there are certain targets that
>>>> Unix compiles can't hit (specifically < net40 and client profiles), which
>>>> would probably explain the permissions. Not a lot I can do about it though,
>>>> that I know of. If it's an issue and someone knows how to convince win32
>>>> zippers to do Unix permissions, I'm all ears.
>>>>
>>>> -d
>>>>
>>>> On October 18, 2020 20:07:18 Matt Sicker wrote:
>>>>
>>>>>
>>>>> Signatures and checksums are good. Once I extracted the zips, though,
>>>>> I see they have some strange permissions configured. All the
>>>>> directories have a chmod of rw-rw-rw (just like all the files do), but
>>>>> they should be rwxr-xr-x. Example output from zipinfo comparing
>>>>> log4net zip with log4j zip:
>>>>>
>>>>> Archive: apache-log4j-2.13.3-bin.zip
>>>>> Zip file size: 14581816 bytes, number of entries: 74
>>>>> drwxr-xr-x 2.0 unx 0 b- stor 20-May-10 12:06
>>>>> apache-log4j-2.13.3-bin/
>>>>> -rw-r--r-- 2.0 unx 2888 bl defN 20-May-10 11:56
>>>>> apache-log4j-2.13.3-bin/RELEASE-NOTES.md
>>>>> ...
>>>>>
>>>>> Archive: apache-log4net-binaries-2.0.12.zip
>>>>> Zip file size: 2154452 bytes, number of entries: 28
>>>>> drw-rw-rw- 6.3 unx 0 b- stor 20-Oct-18 17:22 net20/
>>>>> ...
>>>>> -rw-rw-rw- 6.3 unx 262144 b- defN 20-Oct-18 17:22 net20/log4net.dll
>>>>> ...
>>>>>
>>>>> The directories need to be executable to be able to list files from
>>>>> them (Unix/POSIX). I'm not sure how these zip files got these
>>>>> permissions. I see that the previous 2.0.10 release of log4net has the
>>>>> same problem, though.
>>>>>
>>>>> On Sun, 18 Oct 2020 at 11:03, Davyd McColl wrote:
>>>>>
>>>>>> Hi all
>>>>>>
>>>>>> Not much has changed in 2.0.12 except that an issue affecting
>>>>>> non-windows users has been addressed. LOG4NET-652 and LOG4NET-653 both 
>>>>>> stem
>>>>>> from the same source, wherein the username for the current logging thread
>>>&g

Re: [LOG4NET] Vote for release: 2.0.12

[Davyd McColl]

Hi Matt

Looks like the culprit is gulp-zip, specifically, the source I see sets 
mode for files but not folders (with a source comment about why and a link 
to some other issue). Since there are people with issues open since 2016 
and I don't see a way to change this behavior with arguments, this looks 
like yet another npm module I'll have to fork and maintain myself (or copy, 
embed and fix in log4net, at the very least). May take me a little while.


-d


On October 18, 2020 22:24:41 Matt Sicker  wrote:


I've tried extracting it via unzip, tar, and the built in macOS GUI
unzipper, and all three respect the permissions specified which cause
permissions errors on unix. Being that this release is to help fix
something for non-windows users, it'll be hard for them to use any of
the artifacts besides the nupkg (which is likely the more frequently
used artifact I'd imagine). Doing a zipinfo on the nupkg file notes
that it's encoded using zip 2.0 in fat permissions format while the
source and binary zips are encoded from zip 6.3 in unix permissions
format.

What you might want to figure out is how to make the win32 zippers
_not_ add unix permissions since they're doing it wrong. :)

On Sun, 18 Oct 2020 at 13:55, Davyd McColl  wrote:


Hi Matt

Zip files are created from windows as there are certain targets that Unix 
compiles can't hit (specifically < net40 and client profiles), which would 
probably explain the permissions. Not a lot I can do about it though, that 
I know of. If it's an issue and someone knows how to convince win32 zippers 
to do Unix permissions, I'm all ears.


-d

On October 18, 2020 20:07:18 Matt Sicker  wrote:


Signatures and checksums are good. Once I extracted the zips, though,
I see they have some strange permissions configured. All the
directories have a chmod of rw-rw-rw (just like all the files do), but
they should be rwxr-xr-x. Example output from zipinfo comparing
log4net zip with log4j zip:

Archive:  apache-log4j-2.13.3-bin.zip
Zip file size: 14581816 bytes, number of entries: 74
drwxr-xr-x  2.0 unx0 b- stor 20-May-10 12:06 apache-log4j-2.13.3-bin/
-rw-r--r--  2.0 unx 2888 bl defN 20-May-10 11:56
apache-log4j-2.13.3-bin/RELEASE-NOTES.md
...

Archive:  apache-log4net-binaries-2.0.12.zip
Zip file size: 2154452 bytes, number of entries: 28
drw-rw-rw-  6.3 unx0 b- stor 20-Oct-18 17:22 net20/
...
-rw-rw-rw-  6.3 unx   262144 b- defN 20-Oct-18 17:22 net20/log4net.dll
...

The directories need to be executable to be able to list files from
them (Unix/POSIX). I'm not sure how these zip files got these
permissions. I see that the previous 2.0.10 release of log4net has the
same problem, though.

On Sun, 18 Oct 2020 at 11:03, Davyd McColl  wrote:



Hi all

Not much has changed in 2.0.12 except that an issue affecting non-windows 
users has been addressed. LOG4NET-652 and LOG4NET-653 both stem from the 
same source, wherein the username for the current logging thread was not 
correctly retrieved on non-windows platforms and would throw a 
PlatformNotSupported error. I was hoping that one of the authors of pull 
requests to resolve this would respond to my comments on said pull 
requests, but it's been a while now and there's been a user asking when the 
update would be released, so, as much as I would have liked the community 
member commits, I've gone ahead and applied the logic myself.


Anyways, 2.0.12 is up for release at 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12 
[https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12] with 
signed artifacts there. Documentation is updated at the staging site -- all 
that's left is a sanity check and vote before I can push the nupkg to 
nuget.org, which is how most people will consume it.


Ralph, as far as I understand, I still don't have the ability to push 
artifacts to the apache download server, so please could you do so for me?


Thanks for your time
-d



--
Matt Sicker 




--
Matt Sicker 

Re: [LOG4NET] Vote for release: 2.0.12

[Davyd McColl]

Hi Matt

Zip files are created from windows as there are certain targets that Unix 
compiles can't hit (specifically < net40 and client profiles), which would 
probably explain the permissions. Not a lot I can do about it though, that 
I know of. If it's an issue and someone knows how to convince win32 zippers 
to do Unix permissions, I'm all ears.


-d


On October 18, 2020 20:07:18 Matt Sicker  wrote:


Signatures and checksums are good. Once I extracted the zips, though,
I see they have some strange permissions configured. All the
directories have a chmod of rw-rw-rw (just like all the files do), but
they should be rwxr-xr-x. Example output from zipinfo comparing
log4net zip with log4j zip:

Archive:  apache-log4j-2.13.3-bin.zip
Zip file size: 14581816 bytes, number of entries: 74
drwxr-xr-x  2.0 unx0 b- stor 20-May-10 12:06 apache-log4j-2.13.3-bin/
-rw-r--r--  2.0 unx 2888 bl defN 20-May-10 11:56
apache-log4j-2.13.3-bin/RELEASE-NOTES.md
...

Archive:  apache-log4net-binaries-2.0.12.zip
Zip file size: 2154452 bytes, number of entries: 28
drw-rw-rw-  6.3 unx0 b- stor 20-Oct-18 17:22 net20/
...
-rw-rw-rw-  6.3 unx   262144 b- defN 20-Oct-18 17:22 net20/log4net.dll
...

The directories need to be executable to be able to list files from
them (Unix/POSIX). I'm not sure how these zip files got these
permissions. I see that the previous 2.0.10 release of log4net has the
same problem, though.

On Sun, 18 Oct 2020 at 11:03, Davyd McColl  wrote:


Hi all

Not much has changed in 2.0.12 except that an issue affecting non-windows 
users has been addressed. LOG4NET-652 and LOG4NET-653 both stem from the 
same source, wherein the username for the current logging thread was not 
correctly retrieved on non-windows platforms and would throw a 
PlatformNotSupported error. I was hoping that one of the authors of pull 
requests to resolve this would respond to my comments on said pull 
requests, but it's been a while now and there's been a user asking when the 
update would be released, so, as much as I would have liked the community 
member commits, I've gone ahead and applied the logic myself.


Anyways, 2.0.12 is up for release at 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12 
[https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12] with 
signed artifacts there. Documentation is updated at the staging site -- all 
that's left is a sanity check and vote before I can push the nupkg to 
nuget.org, which is how most people will consume it.


Ralph, as far as I understand, I still don't have the ability to push 
artifacts to the apache download server, so please could you do so for me?


Thanks for your time
-d




--
Matt Sicker 

[LOG4NET] Vote for release: 2.0.12

[Davyd McColl]

Hi all

Not much has changed in 2.0.12 except that an issue affecting non-windows users 
has been addressed. LOG4NET-652 and LOG4NET-653 both stem from the same source, 
wherein the username for the current logging thread was not correctly retrieved 
on non-windows platforms and would throw a PlatformNotSupported error. I was 
hoping that one of the authors of pull requests to resolve this would respond 
to my comments on said pull requests, but it's been a while now and there's 
been a user asking when the update would be released, so, as much as I would 
have liked the community member commits, I've gone ahead and applied the logic 
myself.

Anyways, 2.0.12 is up for release at 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12 
[https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12] with 
signed artifacts there. Documentation is updated at the staging site -- all 
that's left is a sanity check and vote before I can push the nupkg to 
nuget.org, which is how most people will consume it.

Ralph, as far as I understand, I still don't have the ability to push artifacts 
to the apache download server, so please could you do so for me?

Thanks for your time
-d

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Thanks all; I've completed the release as far as I can (Ralph, please push the 
relevant artifacts from 
https://github.com/apache/logging-log4net/releases/tag/rel%2F2.0.11 the last 
mile) and pushed the nuget package.

-d

On 2020/09/22 17:34:34, Matt Sicker  wrote:
+1

On Tue, Sep 22, 2020 at 04:23 Dominik Psenner wrote:

> +1
>
>
>
> --
>
> Sent from my phone. Typos are a kind gift to anyone who happens to find
>
> them.
>
>
>
> On Tue, Sep 22, 2020, 08:37 Davyd McColl wrote:
>
>
>
> > Hi all
>
> >
>
> > I'd appreciate any more +1's (thanks, Remko!). I'd like to get this out
>
> > the door because it fixes confusing versioning on the released binaries
> (in
>
> > particular, nuget consumers)
>
> >
>
> > Thanks
>
> > -d
>
> > On 2020/09/20 22:33:49, Matt Sicker wrote:
>
> > I can use whatever.
>
> >
>
> > On Sun, 20 Sep 2020 at 15:26, Ralph Goers wrote:
>
> > >
>
> > > I don’t have google meet and I can’t use Skype since Microsoft hosed my
>
> > authentication. I have zoom. My company uses Amazon Chime, which is
> fairly
>
> > new, as part of our product offering. I’ve sent you both emails for a
>
> > meeting using that.
>
> > >
>
> > > Ralph
>
> > >
>
> > > > On Sep 20, 2020, at 1:01 PM, Matt Sicker wrote:
>
> > > >
>
> > > > I sent a Google Meet invite to you.
>
> > > >
>
> > > > On Sun, 20 Sep 2020 at 14:26, Davyd McColl wrote:
>
> > > >>
>
> > > >> I'm happy to be available at 8am my side, if that works for everyone
>
> > else.
>
> > > >> It sounds like earlier would be better, but I'm doing the morning
>
> > school
>
> > > >> run from 7am and can't guarantee I'll be back significantly before
>
> > 8am.
>
> > > >>
>
> > > >> How to do this? I have zoom and slack on my work machine, can
> install
>
> > > >> Skype if that's more convenient, can do google meet, I assume,
> though
>
> > > >> haven't ever tried, so may need a bit of a crash intro.
>
> > > >>
>
> > > >> If posting meeting details to the mailing list is not on, feel free
> to
>
> > > >> email me directly (:
>
> > > >>
>
> > > >> -d
>
> > > >>
>
> > > >>
>
> > > >> On September 20, 2020 20:58:29 Ralph Goers wrote:
>
> > > >>
>
> > > >>> 8am in Durban South Africa is 11pm the night before in Phoenix AZ.
>
> > > >>> However, I frequently am up until midnight so that could work.
>
> > 5-5:30 pm is
>
> > > >>> 7:30-8 am in Phoenix. I usually am not in front of my computer on a
>
> > weekday
>
> > > >>> until 8 am but on occasion I can do earlier.
>
> > > >>>
>
> > > >>> Ralph
>
> > > >>>
>
> > > >>>> On Sep 20, 2020, at 9:46 AM, Davyd McColl wrote:
>
> > > >>>>
>
> > > >>>> Any time 08h00 - 17h30 utc+2, except 13h00-14h00 (that's when I
>
> > fetch my
>
> > > >>>> son from school)
>
> > > >>>>
>
> > > >>>> -d
>
> > > >>>>
>
> > > >>>>
>
> > > >>>> On September 20, 2020 18:44:19 Matt Sicker wrote:
>
> > > >>>>
>
> > > >>>>> We’re not quite as strict as Debian for keys (though if you can
>
> > find a
>
> > > >>>>> Debian group locally, they’re great for key signing). The video
>
> > call idea
>
> > > >>>>> could work for exchanging keys. What times would you be available
>
> > to do
>
> > > >>>>> that?
>
> > > >>>>>
>
> > > >>>>> On Sun, Sep 20, 2020 at 03:09 Davyd McColl wrote:
>
> > > >>>>>
>
> > > >>>>>> Hi Ralph
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>>
>
> > > >>>>>> I think I miscommunicated: I'm not regenerating my signing key -
>
> > just the
>
> > > >>>>>>
>
> > > >>>>>> nuget API key f

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Hi all

I'd appreciate any more +1's (thanks, Remko!). I'd like to get this out the 
door because it fixes confusing versioning on the released binaries (in 
particular, nuget consumers)

Thanks
-d
On 2020/09/20 22:33:49, Matt Sicker  wrote:
I can use whatever.

On Sun, 20 Sep 2020 at 15:26, Ralph Goers wrote:
>
> I don’t have google meet and I can’t use Skype since Microsoft hosed my 
> authentication. I have zoom. My company uses Amazon Chime, which is fairly 
> new, as part of our product offering. I’ve sent you both emails for a meeting 
> using that.
>
> Ralph
>
> > On Sep 20, 2020, at 1:01 PM, Matt Sicker wrote:
> >
> > I sent a Google Meet invite to you.
> >
> > On Sun, 20 Sep 2020 at 14:26, Davyd McColl wrote:
> >>
> >> I'm happy to be available at 8am my side, if that works for everyone else.
> >> It sounds like earlier would be better, but I'm doing the morning school
> >> run from 7am and can't guarantee I'll be back significantly before 8am.
> >>
> >> How to do this? I have zoom and slack on my work machine, can install
> >> Skype if that's more convenient, can do google meet, I assume, though
> >> haven't ever tried, so may need a bit of a crash intro.
> >>
> >> If posting meeting details to the mailing list is not on, feel free to
> >> email me directly (:
> >>
> >> -d
> >>
> >>
> >> On September 20, 2020 20:58:29 Ralph Goers wrote:
> >>
> >>> 8am in Durban South Africa is 11pm the night before in Phoenix AZ.
> >>> However, I frequently am up until midnight so that could work. 5-5:30 pm 
> >>> is
> >>> 7:30-8 am in Phoenix. I usually am not in front of my computer on a 
> >>> weekday
> >>> until 8 am but on occasion I can do earlier.
> >>>
> >>> Ralph
> >>>
> >>>> On Sep 20, 2020, at 9:46 AM, Davyd McColl wrote:
> >>>>
> >>>> Any time 08h00 - 17h30 utc+2, except 13h00-14h00 (that's when I fetch my
> >>>> son from school)
> >>>>
> >>>> -d
> >>>>
> >>>>
> >>>> On September 20, 2020 18:44:19 Matt Sicker wrote:
> >>>>
> >>>>> We’re not quite as strict as Debian for keys (though if you can find a
> >>>>> Debian group locally, they’re great for key signing). The video call 
> >>>>> idea
> >>>>> could work for exchanging keys. What times would you be available to do
> >>>>> that?
> >>>>>
> >>>>> On Sun, Sep 20, 2020 at 03:09 Davyd McColl wrote:
> >>>>>
> >>>>>> Hi Ralph
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I think I miscommunicated: I'm not regenerating my signing key - just 
> >>>>>> the
> >>>>>>
> >>>>>> nuget API key for package upload. This forces me to log in in nuget.org
> >>>>>>
> >>>>>> which has 2fa and then I only use that key on the cli for the immediate
> >>>>>> upload.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> My gpg key as at https://GitHub.com/fluffynuts.gpg is the same that I
> >>>>>> used
> >>>>>>
> >>>>>> last time.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -d
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On September 20, 2020 09:01:36 Ralph Goers
> >>>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> In the long run you don’t want to be regenerating your signing key for
> >>>>>>
> >>>>>>> every release. The point is that you would upload the key to a central
> >>>>>>
> >>>>>>> keystore and other people would sign it there. At ApacheCon we would
> >>>>>> have a
> >>>>>>
> >>>>>>> key signing “party” where we recorded each others keys and then would
> >>>>>> take
> >>>>>>
> >>>>>>> our list and update the central keystore. When p

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

I'm happy to be available at 8am my side, if that works for everyone else. 
It sounds like earlier would be better, but I'm doing the morning school 
run from 7am and can't guarantee I'll be back significantly before 8am.


How to do this? I have zoom and slack on my work machine, can install 
Skype if that's more convenient, can do google meet, I assume, though 
haven't ever tried, so may need a bit of a crash intro.


If posting meeting details to the mailing list is not on, feel free to 
email me directly (:


-d


On September 20, 2020 20:58:29 Ralph Goers  wrote:

8am in Durban South Africa is 11pm the night before in Phoenix AZ.  
However, I frequently am up until midnight so that could work. 5-5:30 pm is 
7:30-8 am in Phoenix. I usually am not in front of my computer on a weekday 
until 8 am but on occasion I can do earlier.


Ralph


On Sep 20, 2020, at 9:46 AM, Davyd McColl  wrote:

Any time 08h00 - 17h30 utc+2, except 13h00-14h00 (that's when I fetch my 
son from school)


-d


On September 20, 2020 18:44:19 Matt Sicker  wrote:


We’re not quite as strict as Debian for keys (though if you can find a
Debian group locally, they’re great for key signing). The video call idea
could work for exchanging keys. What times would you be available to do
that?

On Sun, Sep 20, 2020 at 03:09 Davyd McColl  wrote:


Hi Ralph



I think I miscommunicated: I'm not regenerating my signing key - just the

nuget API key for package upload. This forces me to log in in nuget.org

which has 2fa and then I only use that key on the cli for the immediate
upload.



My gpg key as at https://GitHub.com/fluffynuts.gpg is the same that I
used

last time.



-d





On September 20, 2020 09:01:36 Ralph Goers 
wrote:



> In the long run you don’t want to be regenerating your signing key for

> every release. The point is that you would upload the key to a central

> keystore and other people would sign it there. At ApacheCon we would
have a

> key signing “party” where we recorded each others keys and then would
take

> our list and update the central keystore. When people verify the key
they

> can look at the keystore and see that it is signed by a number of
people,

> who then have their keys by a number of people and so on so you are

> building a web of trust.  Sooner or later there will be someone in that
web

> that you personally know and trust.

>

> Ralph

>

>> On Sep 19, 2020, at 11:26 PM, Davyd McColl  wrote:

>>

>> Thanks Matt, I've updated the artifacts on GitHub to have detached

>> signatures. I had previously also uploaded my key to sks-keyservers.net,


>> but I've also uploaded to MIT, though search there always times out.

>>

>> The document you've linked mentions face-to-face interactions to get my
key

>> into the official KEYS file. Not sure how many apache people are at my
end

>> of the world (Durban, South Africa), but I can do an online meeting if
that

>> helps. Last release, Ralph said I should sign, so I did. I'm new to
signing

>> release artifacts - I've generally relied on authentication during
upload

>> as verification of authenticity, with 2FA wherever possible (GitHub and

>> NPM; nuget survives with an apikey - but for the last 2 releases, I've

>> regenerated the key on each use and only supplied it on the cli at
upload,

>> so as not to store it locally)

>>

>> -d

>>

>>

>> On September 19, 2020 22:23:41 Matt Sicker  wrote:

>>

>>> Oh and there's a bit of an issue with the signed files: it looks like

>>> you included _signed files_ rather than detached signatures. Thus, the

>>> .asc files are only verifying themselves rather than the accompanying

>>> file.

>>>

>>> There's a --detached option in gpg for this (yeah, it's always had a
bad UI).

>>>

>>> On Sat, 19 Sep 2020 at 15:19, Matt Sicker  wrote:

>>>>

>>>> The KEYS file [1] that's linked on the download page does not have

>>>> your key in it. Neither does other KEYS file [2]. Check out [3] for

>>>> more info.

>>>>

>>>> [1]: https://downloads.apache.org/logging/log4net/KEYS

>>>> [2]: https://downloads.apache.org/logging/KEYS

>>>> [3]: https://infra.apache.org/release-signing.html#keys-policy

>>>>

>>>>

>>>>

>>>> On Sat, 19 Sep 2020 at 12:48, Davyd McColl  wrote:

>>>> >

>>>> > Thanks Matt, I've done so. Hopefully that makes it easier to verify

>>>> > artifacts that I have signed.

>>>> >

>>>> > -d

>>>> >

>>>> >

>>>> > On 

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Any time 08h00 - 17h30 utc+2, except 13h00-14h00 (that's when I fetch my 
son from school)


-d


On September 20, 2020 18:44:19 Matt Sicker  wrote:


We’re not quite as strict as Debian for keys (though if you can find a
Debian group locally, they’re great for key signing). The video call idea
could work for exchanging keys. What times would you be available to do
that?

On Sun, Sep 20, 2020 at 03:09 Davyd McColl  wrote:


Hi Ralph



I think I miscommunicated: I'm not regenerating my signing key - just the

nuget API key for package upload. This forces me to log in in nuget.org

which has 2fa and then I only use that key on the cli for the immediate
upload.



My gpg key as at https://GitHub.com/fluffynuts.gpg is the same that I
used

last time.



-d





On September 20, 2020 09:01:36 Ralph Goers 
wrote:



> In the long run you don’t want to be regenerating your signing key for

> every release. The point is that you would upload the key to a central

> keystore and other people would sign it there. At ApacheCon we would
have a

> key signing “party” where we recorded each others keys and then would
take

> our list and update the central keystore. When people verify the key
they

> can look at the keystore and see that it is signed by a number of
people,

> who then have their keys by a number of people and so on so you are

> building a web of trust.  Sooner or later there will be someone in that
web

> that you personally know and trust.

>

> Ralph

>

>> On Sep 19, 2020, at 11:26 PM, Davyd McColl  wrote:

>>

>> Thanks Matt, I've updated the artifacts on GitHub to have detached

>> signatures. I had previously also uploaded my key to sks-keyservers.net,


>> but I've also uploaded to MIT, though search there always times out.

>>

>> The document you've linked mentions face-to-face interactions to get my
key

>> into the official KEYS file. Not sure how many apache people are at my
end

>> of the world (Durban, South Africa), but I can do an online meeting if
that

>> helps. Last release, Ralph said I should sign, so I did. I'm new to
signing

>> release artifacts - I've generally relied on authentication during
upload

>> as verification of authenticity, with 2FA wherever possible (GitHub and

>> NPM; nuget survives with an apikey - but for the last 2 releases, I've

>> regenerated the key on each use and only supplied it on the cli at
upload,

>> so as not to store it locally)

>>

>> -d

>>

>>

>> On September 19, 2020 22:23:41 Matt Sicker  wrote:

>>

>>> Oh and there's a bit of an issue with the signed files: it looks like

>>> you included _signed files_ rather than detached signatures. Thus, the

>>> .asc files are only verifying themselves rather than the accompanying

>>> file.

>>>

>>> There's a --detached option in gpg for this (yeah, it's always had a
bad UI).

>>>

>>> On Sat, 19 Sep 2020 at 15:19, Matt Sicker  wrote:

>>>>

>>>> The KEYS file [1] that's linked on the download page does not have

>>>> your key in it. Neither does other KEYS file [2]. Check out [3] for

>>>> more info.

>>>>

>>>> [1]: https://downloads.apache.org/logging/log4net/KEYS

>>>> [2]: https://downloads.apache.org/logging/KEYS

>>>> [3]: https://infra.apache.org/release-signing.html#keys-policy

>>>>

>>>>

>>>>

>>>> On Sat, 19 Sep 2020 at 12:48, Davyd McColl  wrote:

>>>> >

>>>> > Thanks Matt, I've done so. Hopefully that makes it easier to verify

>>>> > artifacts that I have signed.

>>>> >

>>>> > -d

>>>> >

>>>> >

>>>> > On September 18, 2020 23:11:48 Matt Sicker 
wrote:

>>>> >

>>>> > > If you upload your key to your GitHub profile, that also makes it

>>>> > > simple to find. For example, just add ".gpg" to your profile URL:

>>>> > > https://github.com/fluffynuts.gpg

>>>> > >

>>>> > > On Fri, 18 Sep 2020 at 16:08, Remko Popma 
wrote:

>>>> > >>

>>>> > >> +1 remko

>>>> > >>

>>>> > >> On Sat, Sep 19, 2020 at 5:56 AM Matt Sicker 
wrote:

>>>> > >>

>>>> > >> > How about your gpg key? I don't think we've imported that to
the KEYS

>>>> > >> > file as far as I can tell?

>>>> > >> >

>>>> > >> > On Fri, 18 Sep 2020 at

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Hi Ralph

I think I miscommunicated: I'm not regenerating my signing key - just the 
nuget API key for package upload. This forces me to log in in nuget.org 
which has 2fa and then I only use that key on the cli for the immediate upload.


My gpg key as at https://GitHub.com/fluffynuts.gpg is the same that I used 
last time.


-d


On September 20, 2020 09:01:36 Ralph Goers  wrote:

In the long run you don’t want to be regenerating your signing key for 
every release. The point is that you would upload the key to a central 
keystore and other people would sign it there. At ApacheCon we would have a 
key signing “party” where we recorded each others keys and then would take 
our list and update the central keystore. When people verify the key they 
can look at the keystore and see that it is signed by a number of people, 
who then have their keys by a number of people and so on so you are 
building a web of trust.  Sooner or later there will be someone in that web 
that you personally know and trust.


Ralph


On Sep 19, 2020, at 11:26 PM, Davyd McColl  wrote:

Thanks Matt, I've updated the artifacts on GitHub to have detached 
signatures. I had previously also uploaded my key to sks-keyservers.net, 
but I've also uploaded to MIT, though search there always times out.


The document you've linked mentions face-to-face interactions to get my key 
into the official KEYS file. Not sure how many apache people are at my end 
of the world (Durban, South Africa), but I can do an online meeting if that 
helps. Last release, Ralph said I should sign, so I did. I'm new to signing 
release artifacts - I've generally relied on authentication during upload 
as verification of authenticity, with 2FA wherever possible (GitHub and 
NPM; nuget survives with an apikey - but for the last 2 releases, I've 
regenerated the key on each use and only supplied it on the cli at upload, 
so as not to store it locally)


-d


On September 19, 2020 22:23:41 Matt Sicker  wrote:


Oh and there's a bit of an issue with the signed files: it looks like
you included _signed files_ rather than detached signatures. Thus, the
.asc files are only verifying themselves rather than the accompanying
file.

There's a --detached option in gpg for this (yeah, it's always had a bad UI).

On Sat, 19 Sep 2020 at 15:19, Matt Sicker  wrote:


The KEYS file [1] that's linked on the download page does not have
your key in it. Neither does other KEYS file [2]. Check out [3] for
more info.

[1]: https://downloads.apache.org/logging/log4net/KEYS
[2]: https://downloads.apache.org/logging/KEYS
[3]: https://infra.apache.org/release-signing.html#keys-policy



On Sat, 19 Sep 2020 at 12:48, Davyd McColl  wrote:
>
> Thanks Matt, I've done so. Hopefully that makes it easier to verify
> artifacts that I have signed.
>
> -d
>
>
> On September 18, 2020 23:11:48 Matt Sicker  wrote:
>
> > If you upload your key to your GitHub profile, that also makes it
> > simple to find. For example, just add ".gpg" to your profile URL:
> > https://github.com/fluffynuts.gpg
> >
> > On Fri, 18 Sep 2020 at 16:08, Remko Popma  wrote:
> >>
> >> +1 remko
> >>
> >> On Sat, Sep 19, 2020 at 5:56 AM Matt Sicker  wrote:
> >>
> >> > How about your gpg key? I don't think we've imported that to the KEYS
> >> > file as far as I can tell?
> >> >
> >> > On Fri, 18 Sep 2020 at 15:53, Matt Sicker  wrote:
> >> > >
> >> > > Oh sorry, I didn't notice that you uploaded them there (wasn't even
> >> > > aware that it was possible to be honest).
> >> > >
> >> > > On Fri, 18 Sep 2020 at 14:43, Davyd McColl  wrote:
> >> > > >
> >> > > > Hi Matt
> >> > > >
> >> > > > Release artifacts are available on the GitHub release page
> >> > > > (https://GitHub.com/Apache/logging-log4net/releases) - expand the
> >> > assets
> >> > > > list if it's collapsed.
> >> > > >
> >> > > > I'll need someone to upload them to the downloads source as I 
think I

> >> > don't
> >> > > > have access to do so (if I'm wrong, I'd love to be corrected, 
because

> >> > I'd
> >> > > > be less of an annoyance then!). Ralph has stepped in to help here in
> >> > the past.
> >> > > >
> >> > > > -d
> >> > > >
> >> > > >
> >> > > > On September 18, 2020 20:09:07 Matt Sicker  wrote:
> >> > > >
> >> > > > > Do you have links to 

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Thanks Matt, I've updated the artifacts on GitHub to have detached 
signatures. I had previously also uploaded my key to sks-keyservers.net, 
but I've also uploaded to MIT, though search there always times out.


The document you've linked mentions face-to-face interactions to get my key 
into the official KEYS file. Not sure how many apache people are at my end 
of the world (Durban, South Africa), but I can do an online meeting if that 
helps. Last release, Ralph said I should sign, so I did. I'm new to signing 
release artifacts - I've generally relied on authentication during upload 
as verification of authenticity, with 2FA wherever possible (GitHub and 
NPM; nuget survives with an apikey - but for the last 2 releases, I've 
regenerated the key on each use and only supplied it on the cli at upload, 
so as not to store it locally)


-d


On September 19, 2020 22:23:41 Matt Sicker  wrote:


Oh and there's a bit of an issue with the signed files: it looks like
you included _signed files_ rather than detached signatures. Thus, the
.asc files are only verifying themselves rather than the accompanying
file.

There's a --detached option in gpg for this (yeah, it's always had a bad UI).

On Sat, 19 Sep 2020 at 15:19, Matt Sicker  wrote:


The KEYS file [1] that's linked on the download page does not have
your key in it. Neither does other KEYS file [2]. Check out [3] for
more info.

[1]: https://downloads.apache.org/logging/log4net/KEYS
[2]: https://downloads.apache.org/logging/KEYS
[3]: https://infra.apache.org/release-signing.html#keys-policy



On Sat, 19 Sep 2020 at 12:48, Davyd McColl  wrote:
>
> Thanks Matt, I've done so. Hopefully that makes it easier to verify
> artifacts that I have signed.
>
> -d
>
>
> On September 18, 2020 23:11:48 Matt Sicker  wrote:
>
> > If you upload your key to your GitHub profile, that also makes it
> > simple to find. For example, just add ".gpg" to your profile URL:
> > https://github.com/fluffynuts.gpg
> >
> > On Fri, 18 Sep 2020 at 16:08, Remko Popma  wrote:
> >>
> >> +1 remko
> >>
> >> On Sat, Sep 19, 2020 at 5:56 AM Matt Sicker  wrote:
> >>
> >> > How about your gpg key? I don't think we've imported that to the KEYS
> >> > file as far as I can tell?
> >> >
> >> > On Fri, 18 Sep 2020 at 15:53, Matt Sicker  wrote:
> >> > >
> >> > > Oh sorry, I didn't notice that you uploaded them there (wasn't even
> >> > > aware that it was possible to be honest).
> >> > >
> >> > > On Fri, 18 Sep 2020 at 14:43, Davyd McColl  wrote:
> >> > > >
> >> > > > Hi Matt
> >> > > >
> >> > > > Release artifacts are available on the GitHub release page
> >> > > > (https://GitHub.com/Apache/logging-log4net/releases) - expand the
> >> > assets
> >> > > > list if it's collapsed.
> >> > > >
> >> > > > I'll need someone to upload them to the downloads source as I 
think I

> >> > don't
> >> > > > have access to do so (if I'm wrong, I'd love to be corrected, 
because

> >> > I'd
> >> > > > be less of an annoyance then!). Ralph has stepped in to help here in
> >> > the past.
> >> > > >
> >> > > > -d
> >> > > >
> >> > > >
> >> > > > On September 18, 2020 20:09:07 Matt Sicker  wrote:
> >> > > >
> >> > > > > Do you have links to the release artifacts? The download page 
links

> >> > to
> >> > > > > the live site which doesn't have the artifacts yet since 
they're not

> >> > > > > released yet. :)
> >> > > > >
> >> > > > > On Fri, 18 Sep 2020 at 09:05, Davyd McColl 


> >> > wrote:
> >> > > > >>
> >> > > > >> Hi all
> >> > > > >>
> >> > > > >> I have another potential release available: 2.0.11, tagged as
> >> > rc/2.0.11
> >> > > > >>
> >> > > > >> Changes are really minor:
> >> > > > >> - fixed assembly versioning (all assemblies should report 
2.0.11.0

> >> > as their
> >> > > > >> version now)
> >> > > > >> - properly dispose of StreamWriters within logging appenders
> >> > (thanks to
> >> > > > >> @NicholasNoise)
> >> > > > >>
> >> > > > >> Binaries are up at
> >> > > > >> 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.11

> >> > and I've
> >> > > > >> pushed to asf-staging for logging, now up at
> >> > > > >> https://logging.staged.apache.org/log4net/download_log4net.html
> >> > > > >>
> >> > > > >> Thanks
> >> > > > >> -d
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > Matt Sicker 
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Matt Sicker 
> >> >
> >> >
> >> >
> >> > --
> >> > Matt Sicker 
> >> >
> >
> >
> >
> > --
> > Matt Sicker 



--
Matt Sicker 




--
Matt Sicker 

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Thanks Matt, I've done so. Hopefully that makes it easier to verify 
artifacts that I have signed.


-d


On September 18, 2020 23:11:48 Matt Sicker  wrote:


If you upload your key to your GitHub profile, that also makes it
simple to find. For example, just add ".gpg" to your profile URL:
https://github.com/fluffynuts.gpg

On Fri, 18 Sep 2020 at 16:08, Remko Popma  wrote:


+1 remko

On Sat, Sep 19, 2020 at 5:56 AM Matt Sicker  wrote:

> How about your gpg key? I don't think we've imported that to the KEYS
> file as far as I can tell?
>
> On Fri, 18 Sep 2020 at 15:53, Matt Sicker  wrote:
> >
> > Oh sorry, I didn't notice that you uploaded them there (wasn't even
> > aware that it was possible to be honest).
> >
> > On Fri, 18 Sep 2020 at 14:43, Davyd McColl  wrote:
> > >
> > > Hi Matt
> > >
> > > Release artifacts are available on the GitHub release page
> > > (https://GitHub.com/Apache/logging-log4net/releases) - expand the
> assets
> > > list if it's collapsed.
> > >
> > > I'll need someone to upload them to the downloads source as I think I
> don't
> > > have access to do so (if I'm wrong, I'd love to be corrected, because
> I'd
> > > be less of an annoyance then!). Ralph has stepped in to help here in
> the past.
> > >
> > > -d
> > >
> > >
> > > On September 18, 2020 20:09:07 Matt Sicker  wrote:
> > >
> > > > Do you have links to the release artifacts? The download page links
> to
> > > > the live site which doesn't have the artifacts yet since they're not
> > > > released yet. :)
> > > >
> > > > On Fri, 18 Sep 2020 at 09:05, Davyd McColl 
> wrote:
> > > >>
> > > >> Hi all
> > > >>
> > > >> I have another potential release available: 2.0.11, tagged as
> rc/2.0.11
> > > >>
> > > >> Changes are really minor:
> > > >> - fixed assembly versioning (all assemblies should report 2.0.11.0
> as their
> > > >> version now)
> > > >> - properly dispose of StreamWriters within logging appenders
> (thanks to
> > > >> @NicholasNoise)
> > > >>
> > > >> Binaries are up at
> > > >> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.11
> and I've
> > > >> pushed to asf-staging for logging, now up at
> > > >> https://logging.staged.apache.org/log4net/download_log4net.html
> > > >>
> > > >> Thanks
> > > >> -d
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker 
> >
> >
> >
> > --
> > Matt Sicker 
>
>
>
> --
> Matt Sicker 
>




--
Matt Sicker 

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Hi Matt

Ralph mentioned last time that my key had been incorporated and that I 
should sign myself (which I did), but I like the idea of making it easily 
available at GitHub too. I'll do that when I get a moment.


-d


On September 18, 2020 23:11:48 Matt Sicker  wrote:


If you upload your key to your GitHub profile, that also makes it
simple to find. For example, just add ".gpg" to your profile URL:
https://github.com/fluffynuts.gpg

On Fri, 18 Sep 2020 at 16:08, Remko Popma  wrote:


+1 remko

On Sat, Sep 19, 2020 at 5:56 AM Matt Sicker  wrote:

> How about your gpg key? I don't think we've imported that to the KEYS
> file as far as I can tell?
>
> On Fri, 18 Sep 2020 at 15:53, Matt Sicker  wrote:
> >
> > Oh sorry, I didn't notice that you uploaded them there (wasn't even
> > aware that it was possible to be honest).
> >
> > On Fri, 18 Sep 2020 at 14:43, Davyd McColl  wrote:
> > >
> > > Hi Matt
> > >
> > > Release artifacts are available on the GitHub release page
> > > (https://GitHub.com/Apache/logging-log4net/releases) - expand the
> assets
> > > list if it's collapsed.
> > >
> > > I'll need someone to upload them to the downloads source as I think I
> don't
> > > have access to do so (if I'm wrong, I'd love to be corrected, because
> I'd
> > > be less of an annoyance then!). Ralph has stepped in to help here in
> the past.
> > >
> > > -d
> > >
> > >
> > > On September 18, 2020 20:09:07 Matt Sicker  wrote:
> > >
> > > > Do you have links to the release artifacts? The download page links
> to
> > > > the live site which doesn't have the artifacts yet since they're not
> > > > released yet. :)
> > > >
> > > > On Fri, 18 Sep 2020 at 09:05, Davyd McColl 
> wrote:
> > > >>
> > > >> Hi all
> > > >>
> > > >> I have another potential release available: 2.0.11, tagged as
> rc/2.0.11
> > > >>
> > > >> Changes are really minor:
> > > >> - fixed assembly versioning (all assemblies should report 2.0.11.0
> as their
> > > >> version now)
> > > >> - properly dispose of StreamWriters within logging appenders
> (thanks to
> > > >> @NicholasNoise)
> > > >>
> > > >> Binaries are up at
> > > >> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.11
> and I've
> > > >> pushed to asf-staging for logging, now up at
> > > >> https://logging.staged.apache.org/log4net/download_log4net.html
> > > >>
> > > >> Thanks
> > > >> -d
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker 
> >
> >
> >
> > --
> > Matt Sicker 
>
>
>
> --
> Matt Sicker 
>




--
Matt Sicker 

Re: [VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Hi Matt

Release artifacts are available on the GitHub release page 
(https://GitHub.com/Apache/logging-log4net/releases) - expand the assets 
list if it's collapsed.


I'll need someone to upload them to the downloads source as I think I don't 
have access to do so (if I'm wrong, I'd love to be corrected, because I'd 
be less of an annoyance then!). Ralph has stepped in to help here in the past.


-d


On September 18, 2020 20:09:07 Matt Sicker  wrote:


Do you have links to the release artifacts? The download page links to
the live site which doesn't have the artifacts yet since they're not
released yet. :)

On Fri, 18 Sep 2020 at 09:05, Davyd McColl  wrote:


Hi all

I have another potential release available: 2.0.11, tagged as rc/2.0.11

Changes are really minor:
- fixed assembly versioning (all assemblies should report 2.0.11.0 as their 
version now)
- properly dispose of StreamWriters within logging appenders (thanks to 
@NicholasNoise)


Binaries are up at 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.11 and I've 
pushed to asf-staging for logging, now up at 
https://logging.staged.apache.org/log4net/download_log4net.html


Thanks
-d




--
Matt Sicker 

[VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Hi all

I have another potential release available: 2.0.11, tagged as rc/2.0.11

Changes are really minor:
- fixed assembly versioning (all assemblies should report 2.0.11.0 as their 
version now)
- properly dispose of StreamWriters within logging appenders (thanks to 
@NicholasNoise)

Binaries are up at 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.11 and I've 
pushed to asf-staging for logging, now up at 
https://logging.staged.apache.org/log4net/download_log4net.html

Thanks
-d

[VOTE] [log4net] Release 2.0.11

[Davyd McColl]

Hi all

I have another potential release available: 2.0.11, tagged as rc/2.0.11

Changes are really minor:
- fixed assembly versioning (all assemblies should report 2.0.11.0 as their 
version now)
- properly dispose of StreamWriters within logging appenders (thanks to 
@NicholasNoise)

Binaries are up at 
https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.11 
[https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.11] and I've 
pushed to asf-staging for logging, now up at 
https://logging.staged.apache.org/log4net/download_log4net.html 
[https://logging.staged.apache.org/log4net/download_log4net.html]

Thanks
-d

Re: Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Davyd McColl]

Ok, I've found the culprit -- there's a lot of assembly version sources which 
mention 2.0.9 -- and I'm not entirely sure why some of them are in this project 
(AssemblyVersionInfo.cpp, AssemblyVersionInfo.js, AssemblyVersionInfo.vb). And 
there are two files which set up assembly version information (AssemblyInfo.cs 
and AssemblyVersionInfo.cs)

I'll clean up, get that into master, and, after verifying that the nupkg is 
properly generated, I'll raise a vote for 2.0.11. There are some minor 
enhancements (again from NicholasNoise) in the project (specifically: a fix for 
an invalid version string for one of the client profile version strings and a 
good few places where StreamWriters weren't being disposed, so it's not for 
nought)

Thanks again for notifying me.

-d

On 2020/09/18 13:10:26, Davyd McColl  wrote:
hm, that's not great ): I'll investigate. Thanks for letting me know!

-d

On 2020/09/18 13:05:58, Dominik Psenner  wrote:
See the message below. Apparently something went wrong during the last
release.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

-- Forwarded message -
From: NuGet Gallery
Date: Fri, Sep 18, 2020, 12:10
Subject: [NuGet Gallery] Message for owners of the package 'log4net'
To:


*User andyfisher100 >
sends the following message to the owners of Package 'log4net 2.0.10
'.*

When 2.0.10 was released, the version of the dlls was not changed to match
the package version. All of the dlls remain at version 2.0.9
--
* To stop receiving contact emails as an owner of this package, sign in to
the NuGet Gallery and change your email notification settings
. *


Privacy Statement
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA

Re: Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Davyd McColl]

hm, that's not great ): I'll investigate. Thanks for letting me know!

-d

On 2020/09/18 13:05:58, Dominik Psenner  wrote:
See the message below. Apparently something went wrong during the last
release.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

-- Forwarded message -
From: NuGet Gallery
Date: Fri, Sep 18, 2020, 12:10
Subject: [NuGet Gallery] Message for owners of the package 'log4net'
To:


*User andyfisher100 >
sends the following message to the owners of Package 'log4net 2.0.10
'.*

When 2.0.10 was released, the version of the dlls was not changed to match
the package version. All of the dlls remain at version 2.0.9
--
* To stop receiving contact emails as an owner of this package, sign in to
the NuGet Gallery and change your email notification settings
. *


Privacy Statement
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA

Re: [VOTE] [log4net] Release 2.0.10

[Davyd McColl]

Thanks Ralph

I want aware I could get the site live like that, but now that I know, I'll 
lbs better next time.


-d


On September 12, 2020 20:03:02 Ralph Goers  wrote:

I checked out the asf-site branch and ran “git rebase asf-staging” and then 
committed that. The 2.0.10 site is live.


Ralph


On Sep 12, 2020, at 10:50 AM, Ralph Goers  wrote:

Davyd,

You have full access to all Logging repos at GitHub.  You can publish the 
log4net site yourself just by committing it to the asf-site branch.  The 
only thing preventing that would be if you want others to review the staged 
site before you do that.


In looking at the log4net site, it relies on the .htaccess file to direct 
requests to the correct version. I have modified it to point to the 2.0.10 
release of the site. I tried pointing it to the 2.x symlink but I got a 500 
error when trying to access it that way.


Ralph


On Sep 12, 2020, at 9:02 AM, Davyd McColl  wrote:

Thanks Ralph

I've pushed the nuget package; links to download artifacts in the site 
pushed as oy2ky5qgzop2i5hcbgsayxy3rqtvgqnenj2usfjzgansye to asf-staging 
seem to be fine, tested locally, though I don't see that version of the 
site up at https://logging.staged.apache.org/log4net; however, it's ready 
to go whenever it can be published.


Thanks again
-d

On 2020/09/12 06:00:04, Ralph Goers  wrote:
The artifacts have been committed to 
https://dist.apache.org/repos/dist/release/logging/log4net/.


Ralph


On Sep 11, 2020, at 9:44 AM, Ralph Goers wrote:

Davyd,

That makes 3 +1 PMC votes so you may proceed with the release. Please 
update the web site before you publish to NuGet. I will copy the artifacts 
to the release distribution area for you.


Ralph


On Sep 11, 2020, at 8:19 AM, Dominik Psenner wrote:

+1

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Fri, Sep 11, 2020, 08:08 Remko Popma wrote:


+1
Remko.



(Shameless plug) Every java main() method deserves http://picocli.info


On Sep 10, 2020, at 15:24, Davyd McColl wrote:

Hi all

I realise that I'm causing a bit of a headache by sending mails from my

work account. I'm trying to be more vigilant when sending from my mail
client, but perhaps I need to find a better way, because I just managed to
send again from that account this morning, and I understand that may mean
that messages aren't getting through. I apologise, especially to Ralph,
who, I understand, has had to manually marshal some of my mails through ):


Please can we get a vote going on this release as it
a) sorts out the CVE that people have been so interested in
b) improves things significantly for netstandard 2.0 users

Thanks
-d
On 2020/09/07 21:15:42, Davyd McColl wrote:
Hi Dominik
No, it doesn't. Netstandard 2.0 support is added in addition to the

existing netstandard 1.3 target.

Whilst I'd really like to diminish the target list of the package

(particularly the client profile targets), I'd only be comfortable doing so
on a major version change, and I think that mostly I just want to deprecate
client profiles to enable easier cross-platform dev (those are the only
targets I haven't had joy supporting on Linux so far)

-d

On September 7, 2020 19:55:51 Dominik Psenner

wrote:

Hi
Does this break support for netstandard1.3 and enforces users to update

all

their dependants?
Best regards
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.
On Sun, Sep 6, 2020, 21:04 Davyd McColl wrote:
Hi all

I'd like to propose a vote to release 2.0.10 of log4net, with:
- updated netstandard 2.0 support from community member NicholasNoise
- cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the
mechanism used there is outdated for netstandard 2.0, but the principle
stands

I've created an RC release at
GitHub:

https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 [
https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1] and

pushed updated site material to the `asf-staging` branch of the
logging-log4net-site repo.

Thanks
-d

Re: [VOTE] [log4net] Release 2.0.10

[Davyd McColl]

Thanks Ralph

I've pushed the nuget package; links to download artifacts in the site pushed 
as oy2ky5qgzop2i5hcbgsayxy3rqtvgqnenj2usfjzgansye to asf-staging seem to be 
fine, tested locally, though I don't see that version of the site up at 
https://logging.staged.apache.org/log4net; however, it's ready to go whenever 
it can be published.

Thanks again
-d

On 2020/09/12 06:00:04, Ralph Goers  wrote:
The artifacts have been committed to 
https://dist.apache.org/repos/dist/release/logging/log4net/.

Ralph

> On Sep 11, 2020, at 9:44 AM, Ralph Goers wrote:
>
> Davyd,
>
> That makes 3 +1 PMC votes so you may proceed with the release. Please update 
> the web site before you publish to NuGet. I will copy the artifacts to the 
> release distribution area for you.
>
> Ralph
>
>> On Sep 11, 2020, at 8:19 AM, Dominik Psenner wrote:
>>
>> +1
>>
>> --
>> Sent from my phone. Typos are a kind gift to anyone who happens to find
>> them.
>>
>> On Fri, Sep 11, 2020, 08:08 Remko Popma wrote:
>>
>>> +1
>>> Remko.
>>>
>>>
>>>
>>> (Shameless plug) Every java main() method deserves http://picocli.info
>>>
>>>> On Sep 10, 2020, at 15:24, Davyd McColl wrote:
>>>>
>>>> Hi all
>>>>
>>>> I realise that I'm causing a bit of a headache by sending mails from my
>>> work account. I'm trying to be more vigilant when sending from my mail
>>> client, but perhaps I need to find a better way, because I just managed to
>>> send again from that account this morning, and I understand that may mean
>>> that messages aren't getting through. I apologise, especially to Ralph,
>>> who, I understand, has had to manually marshal some of my mails through ):
>>>>
>>>> Please can we get a vote going on this release as it
>>>> a) sorts out the CVE that people have been so interested in
>>>> b) improves things significantly for netstandard 2.0 users
>>>>
>>>> Thanks
>>>> -d
>>>> On 2020/09/07 21:15:42, Davyd McColl wrote:
>>>> Hi Dominik
>>>> No, it doesn't. Netstandard 2.0 support is added in addition to the
>>> existing netstandard 1.3 target.
>>>> Whilst I'd really like to diminish the target list of the package
>>> (particularly the client profile targets), I'd only be comfortable doing so
>>> on a major version change, and I think that mostly I just want to deprecate
>>> client profiles to enable easier cross-platform dev (those are the only
>>> targets I haven't had joy supporting on Linux so far)
>>>> -d
>>>>
>>>> On September 7, 2020 19:55:51 Dominik Psenner
>>> wrote:
>>>> Hi
>>>> Does this break support for netstandard1.3 and enforces users to update
>>> all
>>>> their dependants?
>>>> Best regards
>>>> --
>>>> Sent from my phone. Typos are a kind gift to anyone who happens to find
>>>> them.
>>>> On Sun, Sep 6, 2020, 21:04 Davyd McColl wrote:
>>>> Hi all
>>>>
>>>> I'd like to propose a vote to release 2.0.10 of log4net, with:
>>>> - updated netstandard 2.0 support from community member NicholasNoise
>>>> - cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the
>>>> mechanism used there is outdated for netstandard 2.0, but the principle
>>>> stands
>>>>
>>>> I've created an RC release at
>>>> GitHub:
>>> https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 [
>>> https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1] and
>>>> pushed updated site material to the `asf-staging` branch of the
>>>> logging-log4net-site repo.
>>>>
>>>> Thanks
>>>> -d
>>>
>
>
>

[log4net] cleaning up JIRA

[Davyd McColl]

Hi all

I'd like to start (at some point) clearing up JIRA a bit and getting on top of 
associated pull requests (for example, the one for a REST appender, 
https://issues.apache.org/jira/projects/LOG4NET/issues/LOG4NET-644) and I'd 
appreciate any guidance on the accepted methods. To clarify, if it were solely 
up to me I'd:

1. close out anything referring to really old versions of log4net or raised 
over 2 years ago (eg 
https://issues.apache.org/jira/projects/LOG4NET/issues/LOG4NET-514) with a 
polite message to please re-submit if the problem persists
2. close out any wishlist items without a corresponding pull request with a 
polite message to the effect that pull requests are welcome.

This is really simply a part of how I normally work -- reduce the noise so that 
I can get stuff done.

-d

Re: [VOTE] [log4net] Release log4net 2.0.10

[Davyd McColl]

Hi Dominik

I have had a long look over the changes (both via the PR and locally, as I 
contributed to help with some infra changes) and I'm happy -- there's been a 
lot of clean-up and simplification and in addition, tests are now run against 
all targets -- so that's a good thing. Some of these changes are required to 
resolve issues for netstandard2.0 users who have upgraded to 2.0.9. Community 
member NicholasNoise put in a lot of work on this.

If it helps, the original PR is here: 
https://github.com/apache/logging-log4net/pull/63 -- it makes viewing changes a 
lot simpler. Changes to a lot of the #ifdefs are updates from NETSTANDARD1_3 to 
simply NETSTANDARD as many of the changes required for netstandard2.0 are 
compatible. I contributed on that PR too, mainly around getting build to work 
as expected.

You're welcome to use the npm-based build / test pipeline to verify: I've just 
updated master to automatically test across all platforms when running `npm 
test`, so it should be easy to verify that all things are functional:
- install node if you don't have it yet (I suggest via nvm)
- `npm ci`
- `npm test`

(assuming that you have all the required build targets -- there are helper .ps1 
scripts to get the older targets -- netcore 1.1 and netfx35)

-d


On 2020/09/10 09:03:45, Dominik Psenner  wrote:
Hi

Sorry to not have responded earlier. Time is short and the days are busy. I
looked at the diff and found several suspicious changes. Several hundred
ifdefs have been removed/replaced along with tests. Therefore I have a bad
feeling about those changes without further careful checking. I propose to
release the cve fix alone and follow up a second release as soon as someone
had the time to verify that the netstandard2 changes are ok.

Best regards
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Sep 10, 2020, 08:48 Davyd McColl wrote:

> Hi
>
> Sorry to be a bother, but I haven't heard anything back on this apart from
> Dominik's inquiry into netstandard 1.3 support. I'd really like to get this
> out as:
> a) it contains the CVE fix that has been asked about so much
> b) it solves some issues affecting netstandard users
>
> Thanks
> -d
>
> On 2020/09/06 20:51:38, Davyd McColl wrote:
> Hi all
>
> I'd like to propose a vote to release 2.0.10 of log4net, with:
> - updated netstandard 2.0 support from community member NicholasNoise
> - cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the
> mechanism used there is outdated for netstandard 2.0, but the principle
> stands
>
> I've created an RC release at GitHub:
> https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 and
> pushed updated site material to the `asf-staging` branch of the
> logging-log4net-site repo.
>
> Thanks
> -d

Re: [VOTE] [log4net] Release log4net 2.0.10

[Davyd McColl]

Hi

Sorry to be a bother, but I haven't heard anything back on this apart from 
Dominik's inquiry into netstandard 1.3 support. I'd really like to get this out 
as:
a) it contains the CVE fix that has been asked about so much
b) it solves some issues affecting netstandard users

Thanks
-d

On 2020/09/06 20:51:38, Davyd McColl  wrote:
Hi all

I'd like to propose a vote to release 2.0.10 of log4net, with:
- updated netstandard 2.0 support from community member NicholasNoise
- cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the 
mechanism used there is outdated for netstandard 2.0, but the principle stands

I've created an RC release at GitHub: 
https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 and pushed 
updated site material to the `asf-staging` branch of the logging-log4net-site 
repo.

Thanks
-d

Re: [VOTE] [log4net] Release 2.0.10

[Davyd McColl]

Hi all

I realise that I'm causing a bit of a headache by sending mails from my work 
account. I'm trying to be more vigilant when sending from my mail client, but 
perhaps I need to find a better way, because I just managed to send again from 
that account this morning, and I understand that may mean that messages aren't 
getting through. I apologise, especially to Ralph, who, I understand, has had 
to manually marshal some of my mails through ):

Please can we get a vote going on this release as it
a) sorts out the CVE that people have been so interested in
b) improves things significantly for netstandard 2.0 users

Thanks
-d
On 2020/09/07 21:15:42, Davyd McColl  wrote:
Hi Dominik
No, it doesn't. Netstandard 2.0 support is added in addition to the existing 
netstandard 1.3 target.
Whilst I'd really like to diminish the target list of the package (particularly 
the client profile targets), I'd only be comfortable doing so on a major 
version change, and I think that mostly I just want to deprecate client 
profiles to enable easier cross-platform dev (those are the only targets I 
haven't had joy supporting on Linux so far)
-d

On September 7, 2020 19:55:51 Dominik Psenner  wrote:
Hi
Does this break support for netstandard1.3 and enforces users to update all
their dependants?
Best regards
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.
On Sun, Sep 6, 2020, 21:04 Davyd McColl  wrote:
Hi all

I'd like to propose a vote to release 2.0.10 of log4net, with:
- updated netstandard 2.0 support from community member NicholasNoise
- cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the
mechanism used there is outdated for netstandard 2.0, but the principle
stands

I've created an RC release at
GitHub: https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 
[https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1] and
pushed updated site material to the `asf-staging` branch of the
logging-log4net-site repo.

Thanks
-d

Re: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

[Davyd McColl]

Thanks for the info!

-d


On September 9, 2020 07:29:28 "Joseph A. MITOLA"  wrote:


Sure, I use Visual Studio 2019 Community edition as my IDE which has a
publish tool to deploy console and web applications. I then push my
deployment files to github and have a scheduled task on the web server that
pulls down the latest commits from the github server.

Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Architecture, Platforms & Integration
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu

On Tue, Sep 8, 2020, 9:59 PM Davyd McColl  wrote:


Thanks! I'm surprised that you had the experience you had, because those
environments are very similar to ours at work. May I ask what process you
use to deploy? We use Octopus.

At least if I see the same odd behaviour, I have one more idea to check (:

-d

On September 9, 2020 00:02:32 "Joseph A. MITOLA" 
wrote:


OK, sure. No webforms. I am maintaining two web applications, one MVC 5
app and one Web API, both running on .Net framework 4.6 and both now
successfully using log4net 2.0.9





*Joseph A. Mitola*, *Information Systems Analyst*
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu





*From: *Davyd McColl 
*Sent: *Tuesday, September 8, 2020 1:18 PM
*To: *Joseph A. MITOLA 
*Cc: *dev@logging.apache.org
*Subject: *RE: issues with log4net 2.0.9 under IIS for projects using
.net framework 4.5+



Joseph

Glad you could figure it out! Sounds like your app is webforms? If not,
if appreciate as much info as you can divulge. I ask because I didn't write
asmdeps on a whimsey - I'm genuinely interested in debugging strange
situations, so the more info I have to help the next person, the better.

Thanks
-d

On September 8, 2020 20:32:25 "Joseph A. MITOLA" 
wrote:

Thanks Davyd,



I found the issue.



First, I had to uninstall the “Microsoft Monitoring Agent” on the windows
server because for some reason when log4net was causing the IIS app pool to
crash, it also crashed the monitoring agent which prevented any log4net
internal debug logs to write to the log file.



Once the monitoring agent was uninstalled, re-launching the application
generated a log4net internal debug file. I noticed the first line in the
file was still referencing version 2.0.8 because it was loading it from the
.Net framework temporary libraries located in:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files



I simply manually deleted the temporary files, re-started IIS and
launched the application. This time everything worked and in the log4net
internal debug file it was now referencing version 2.0.9.



Very strange that I had to run these steps in order to clear the previous
version from the cache but at least it’s working now. Also, I checked “auto
generate binding redirects” in visual studio which automatically generates
these assembly references.



Thanks for all your help,

Joseph





*Joseph A. Mitola*, *Information Systems Analyst*
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu





*From: *Davyd McColl 
*Sent: *Tuesday, September 8, 2020 11:15 AM
*To: *Joseph A. MITOLA 
*Cc: *dev@logging.apache.org
*Subject: *RE: issues with log4net 2.0.9 under IIS for projects using
.net framework 4.5+



Joseph

Let's try figuring out the root cause. I was quite hasty with the rebind
idea, though it may ultimately solve the problem, if my hunch is right.

An assembly rebind is a bit of configuration added to the app.config or
web.config of a .net application that can direct it, at runtime, to change
its behavior slightly when attempting to load a dependant assembly:


https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions

For example, if you had some dependency A which was built against log4net
2.0.8 and you upgraded your web app to 2.0.9, at runtime, your web app
would be happy, but that dependency wouldn't. We can force the hand of the
assembly resolver to tell it, basically, "when someone asks for log4net
2.0.8, give them this assembly here (2.0.9)". If nothing too drastic has
changed in the version increment, all will go well.

This is how I tested 2.0.9 in my work project. We have an intermediate
dependency which abstracts logging (so we can mock out the logger in
testing, and have the freedom to use another logging framework). That
dependency wants 2.0.8 (my PR to update is still in review) and my web app
is updated to 2.0.9. So I use an assembly rebind to convince the runtime to
simply provide the 2.0.9 assembly to to intermediate.

asmdeps may show you what's going on here. Assuming you have an asp.net
mvc app, point asmdeps at the primary assembly (eg Website.dll) and see the
resolved depe

RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

[Davyd McColl]

Thanks! I'm surprised that you had the experience you had, because those 
environments are very similar to ours at work. May I ask what process you 
use to deploy? We use Octopus.


At least if I see the same odd behaviour, I have one more idea to check (:

-d


On September 9, 2020 00:02:32 "Joseph A. MITOLA"  wrote:

OK, sure. No webforms. I am maintaining two web applications, one MVC 5 app 
and one Web API, both running on .Net framework 4.6 and both now 
successfully using log4net 2.0.9


Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu

From: Davyd McColl
Sent: Tuesday, September 8, 2020 1:18 PM
To: Joseph A. MITOLA
Cc: dev@logging.apache.org
Subject: RE: issues with log4net 2.0.9 under IIS for projects using .net 
framework 4.5+


Joseph
Glad you could figure it out! Sounds like your app is webforms? If not, if 
appreciate as much info as you can divulge. I ask because I didn't write 
asmdeps on a whimsey - I'm genuinely interested in debugging strange 
situations, so the more info I have to help the next person, the better.

Thanks
-d
On September 8, 2020 20:32:25 "Joseph A. MITOLA"  wrote:
Thanks Davyd,

I found the issue.

First, I had to uninstall the “Microsoft Monitoring Agent” on the windows 
server because for some reason when log4net was causing the IIS app pool to 
crash, it also crashed the monitoring agent which prevented any log4net 
internal debug logs to write to the log file.


Once the monitoring agent was uninstalled, re-launching the application 
generated a log4net internal debug file. I noticed the first line in the 
file was still referencing version 2.0.8 because it was loading it from the 
.Net framework temporary libraries located in: 
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files


I simply manually deleted the temporary files, re-started IIS and launched 
the application. This time everything worked and in the log4net internal 
debug file it was now referencing version 2.0.9.


Very strange that I had to run these steps in order to clear the previous 
version from the cache but at least it’s working now. Also, I checked “auto 
generate binding redirects” in visual studio which automatically generates 
these assembly references.


Thanks for all your help,
Joseph

Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu

From: Davyd McColl
Sent: Tuesday, September 8, 2020 11:15 AM
To: Joseph A. MITOLA
Cc: dev@logging.apache.org
Subject: RE: issues with log4net 2.0.9 under IIS for projects using .net 
framework 4.5+


Joseph
Let's try figuring out the root cause. I was quite hasty with the rebind 
idea, though it may ultimately solve the problem, if my hunch is right.
An assembly rebind is a bit of configuration added to the app.config or 
web.config of a .net application that can direct it, at runtime, to change 
its behavior slightly when attempting to load a dependant assembly:

https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions
For example, if you had some dependency A which was built against log4net 
2.0.8 and you upgraded your web app to 2.0.9, at runtime, your web app 
would be happy, but that dependency wouldn't. We can force the hand of the 
assembly resolver to tell it, basically, "when someone asks for log4net 
2.0.8, give them this assembly here (2.0.9)". If nothing too drastic has 
changed in the version increment, all will go well.
This is how I tested 2.0.9 in my work project. We have an intermediate 
dependency which abstracts logging (so we can mock out the logger in 
testing, and have the freedom to use another logging framework). That 
dependency wants 2.0.8 (my PR to update is still in review) and my web app 
is updated to 2.0.9. So I use an assembly rebind to convince the runtime to 
simply provide the 2.0.9 assembly to to intermediate.
asmdeps may show you what's going on here. Assuming you have an asp.net mvc 
app, point asmdeps at the primary assembly (eg Website.dll) and see the 
resolved dependency tree. Adding the -p flag will tell you exactly which 
files would be loaded. A missing or mismatched assembly would become 
evident. Since asmdeps relies on the inbuilt assembly resolution 
mechanisms, it will also be "fooled" by a rebind, so if a rebind fixes the 
issue, asmdeps should show no broken dependency.

-d
On September 8, 2020 19:31:45 "Joseph A. MITOLA"  wrote:
I tried uninstalling and re-installing, no effect. I don’t know what you 
mean by rebind?


Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-50

RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

[Davyd McColl]

Joseph

Glad you could figure it out! Sounds like your app is webforms? If not, if 
appreciate as much info as you can divulge. I ask because I didn't write 
asmdeps on a whimsey - I'm genuinely interested in debugging strange 
situations, so the more info I have to help the next person, the better.


Thanks
-d


On September 8, 2020 20:32:25 "Joseph A. MITOLA"  wrote:


Thanks Davyd,

I found the issue.

First, I had to uninstall the “Microsoft Monitoring Agent” on the windows 
server because for some reason when log4net was causing the IIS app pool to 
crash, it also crashed the monitoring agent which prevented any log4net 
internal debug logs to write to the log file.


Once the monitoring agent was uninstalled, re-launching the application 
generated a log4net internal debug file. I noticed the first line in the 
file was still referencing version 2.0.8 because it was loading it from the 
.Net framework temporary libraries located in: 
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files


I simply manually deleted the temporary files, re-started IIS and launched 
the application. This time everything worked and in the log4net internal 
debug file it was now referencing version 2.0.9.


Very strange that I had to run these steps in order to clear the previous 
version from the cache but at least it’s working now. Also, I checked “auto 
generate binding redirects” in visual studio which automatically generates 
these assembly references.


Thanks for all your help,
Joseph

Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu

From: Davyd McColl
Sent: Tuesday, September 8, 2020 11:15 AM
To: Joseph A. MITOLA
Cc: dev@logging.apache.org
Subject: RE: issues with log4net 2.0.9 under IIS for projects using .net 
framework 4.5+


Joseph
Let's try figuring out the root cause. I was quite hasty with the rebind 
idea, though it may ultimately solve the problem, if my hunch is right.
An assembly rebind is a bit of configuration added to the app.config or 
web.config of a .net application that can direct it, at runtime, to change 
its behavior slightly when attempting to load a dependant assembly:

https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions
For example, if you had some dependency A which was built against log4net 
2.0.8 and you upgraded your web app to 2.0.9, at runtime, your web app 
would be happy, but that dependency wouldn't. We can force the hand of the 
assembly resolver to tell it, basically, "when someone asks for log4net 
2.0.8, give them this assembly here (2.0.9)". If nothing too drastic has 
changed in the version increment, all will go well.
This is how I tested 2.0.9 in my work project. We have an intermediate 
dependency which abstracts logging (so we can mock out the logger in 
testing, and have the freedom to use another logging framework). That 
dependency wants 2.0.8 (my PR to update is still in review) and my web app 
is updated to 2.0.9. So I use an assembly rebind to convince the runtime to 
simply provide the 2.0.9 assembly to to intermediate.
asmdeps may show you what's going on here. Assuming you have an asp.net mvc 
app, point asmdeps at the primary assembly (eg Website.dll) and see the 
resolved dependency tree. Adding the -p flag will tell you exactly which 
files would be loaded. A missing or mismatched assembly would become 
evident. Since asmdeps relies on the inbuilt assembly resolution 
mechanisms, it will also be "fooled" by a rebind, so if a rebind fixes the 
issue, asmdeps should show no broken dependency.

-d
On September 8, 2020 19:31:45 "Joseph A. MITOLA"  wrote:
I tried uninstalling and re-installing, no effect. I don’t know what you 
mean by rebind?


Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu

From: Davyd McColl
Sent: Tuesday, September 8, 2020 9:52 AM
To: Joseph A. MITOLA
Cc: dev@logging.apache.org
Subject: RE: issues with log4net 2.0.9 under IIS for projects using .net 
framework 4.5+


Have you tried an assembly rebind to force resolution to 2.0.9?
-d
On September 8, 2020 18:00:45 "Joseph A. MITOLA"  wrote:
Hi Davyd,

The weird thing is everything had been working fine with same 
configuration, framework version 4.6, etc. and all I did was update the 
nuget package for log4net from 2.0.8 to 2.0.9. After that IIS w3wp process 
along with perfmon.dll process on the deployment server crashed when the 
application was launched. No error logs were reported even when I set the 
internal debug to true, nothing. But then, if I revert the nuget package 
back to 2.0.8, everything is normal again including the logs with the 
internal debugging 

Re: Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Davyd McColl]

True that, but I tried to initiate a vote the other day from my work mail 
by mistake and the message was bounced, so I'm not sure what rules apply to 
this list. If it's fairly open, it might be a plan to update the associated 
email address on nuget to the dev list.


-d


On September 8, 2020 19:08:55 Matt Sicker  wrote:


That's this dev list! Though if we need a separate mailing list, we
can always create more.

On Tue, 8 Sep 2020 at 11:54, Davyd McColl  wrote:


What if there was another Apache email address that messages were sent to,
and multiple people could observe that account? I don't mind being one of
the lucky ones if it will help (:

-d


On September 8, 2020 17:47:57 Matt Sicker  wrote:

> The main problem with sending nuget info to the PMC is that nobody in
> the PMC are working on log4net besides validating releases ;)
>
> On Tue, 8 Sep 2020 at 04:37, Dominik Psenner  wrote:
>>
>> In the past security vulnerabilities were reported via nuget and it is not
>> a good idea to publish those in an automated way.
>>
>> I suggest to update the nuget project documentation and prominently point
>> to our mailing lists and discourage the communication via nuget. Users may
>> continue sending messages via nuget to pmc but hopefully the volume is
>> reduced. Unfortunately most users consume log4net via nuget and apparently
>> do not care about the mailing list and/or the official project website.
>>
>> --
>> Sent from my phone. Typos are a kind gift to anyone who happens to find
>> them.
>>
>> On Tue, Sep 8, 2020, 08:34 Davyd McColl  wrote:
>>
>> > Ralph
>> >
>> > I understand that the emails provide a bit of workload, and I'm trying to
>> > figure out a solution to help everyone -- obviously there are people who
>> > submit mails (and wonder where they went) and people who have to handle
>> > those mails.
>> >
>> > We use Trello at work and have built our own custom solution which bridges
>> > Trello and email (called Sendboard). It looks like
>> >
>> 
https://community.atlassian.com/t5/Jira-questions/create-ticket-from-email-in-jira/qaq-p/806165

>> > gives an idea of how to do something similar for JIRA. Would that perhaps
>> > help to make things flow a bit better?
>> >
>> > Unlike npmjs.com, nuget.org doesn't provide a mechanism for a quick link
>> > to an issues board -- the best I can see is either the project url or the
>> > associated email address (which is probably why most people reach out on
>> > email). So the possible solutions I see here are to
>> > - automate handling the email
>> > - make the issue reporting url clearer on the project page.
>> >
>> > The project url links to logging.apache.org/log4net -- perhaps I should
>> > update the landing page to include a more obvious link to reporting 
issues?

>> > There is already a link in the project's README.md which surfaces on
>> > GitHub. At the end of the day, I'd like the situation to be better for 
both

>> > the PMC and users. I'm open to any suggestions.
>> >
>> > -d
>> >
>> > On 2020/09/08 07:24:25, Davyd McColl  wrote:
>> > Hi Ralph
>> > I'll investigate this today. I'd like more information, particularly
>> > configuration and, eg if the ado.net [http://ado.net] appender is used,
>> > table structures.
>> > Joseph, please open a ticket at
>> > https://issues.apache.org/jira/browse/LOG4NET [
>> > https://issues.apache.org/jira/browse/LOG4NET] to help me track this.
>> > -d
>> >
>> > On September 7, 2020 23:35:12 Ralph Goers 
>> > wrote:
>> > For some reason all messages from NuGet are routed to the Apache Logging
>> > PMC list. This one clearly does not need to be private. Just know that the
>> > person who sent this is apparently not subscribed to the ASF mailing lists
>> > so won’t see a response unless he is cc’d.
>> > I’m not familiar with NuGet but it sure would be nice if they could be
>> > pointed to our mailing lists. The PMC has gotten a fair number of these
>> > that we have tried to respond to.
>> > Ralph
>> > Begin forwarded message:
>> > From: NuGet Gallery 
>> > Subject: [NuGet Gallery] Message for owners of the package 'log4net'
>> > Date: September 7, 2020 at 2:25:32 PM MST
>> > To: 
>> > Reply-To: "Logging PMC" 
>> > Reply-To: 
>> > User jmitola  sends the following message to the
>> > owners of Package 'log4net 2.

RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

[Davyd McColl]

Taking a step back, I'd also like you to check out:

https://github.com/fluffynuts/dotnet-utils

In particular, there are two utils in there which may help with determining 
what's going on, especially if the problem is something early like failure to 
resolve an assembly

In the bin folder, there are:
- toggle-fusion.cmd
- asmdeps.exe

If you're unsure about the latter, you're free to build your own from the 
source in that repo -- the binary is supplied for convenience only

Here's what they do:
toggle-fusion.cmd will toggle fusion logging on the host machine. Be aware that 
fusion logging will negatively impact performance _a lot_ but you'll end up 
with logs in C:\fusion-logs telling you about errors resolving assemblies

asmdeps.exe will give you information about assembly dependencies. By default, 
when it runs, it shows you a colored tree-view of assembly dependencies for the 
assemblies provided on the CLI. You can turn off color and add `-p` to get 
paths for the assemblies that are resolved (and would be loaded at runtime).

Both should help to track down a missing assembly -- whether that's missing 
because there is no {X}.dll or missing because assemblies further up the chain 
are expecting a different version or an assembly with a different public key.

-d

On 2020/09/08 18:52:09, Davyd McColl  wrote:
Have you tried an assembly rebind to force resolution to 2.0.9?
-d
On September 8, 2020 18:00:45 "Joseph A. MITOLA"  wrote:
Hi Davyd,
 
The weird thing is everything had been working fine with same configuration, 
framework version 4.6, etc. and all I did was update the nuget package for 
log4net from 2.0.8 to 2.0.9. After that IIS w3wp process along with perfmon.dll 
process on the deployment server crashed when the application was launched. No 
error logs were reported even when I set the internal debug to true, nothing. 
But then, if I revert the nuget package back to 2.0.8, everything is normal 
again including the logs with the internal debugging turned on. So, it makes me 
think that maybe the 2.0.9 version is missing a dependency library or something 
but I couldn't find anything online to that effect.
 
Here is my config, I'm using RollingFileAppender, AdoNetAppender, and 
SmtpAppender
 

  
    
    
    
    
    
    
    
    
  
    
    
  
  
    
    
    
    
  
  
  
    
    
  
  
  
  
    
  
    
    
  
  
  
  
    
  
    
    
  
  
  
  
    
  
    
    
  
  
  
      
    
  
    
    
  
  
  
  
    
  
  
    
    
    
  
    
    
  
    
    
  
 
  
    
    
    
    
  

 
 
Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu [mailto:jmit...@berkeley.edu]
 
 
From: Davyd McColl [mailto:davyd.mcc...@codeo.co.za]
Sent: Tuesday, September 8, 2020 12:08 AM
To: jmit...@berkeley.edu [mailto:jmit...@berkeley.edu]
Cc: dev@logging.apache.org [mailto:dev@logging.apache.org]
Subject: RE: issues with log4net 2.0.9 under IIS for projects using .net 
framework 4.5+
 
Hi Joseph
 
I've performed a (rather belated) upgrade to log4net 2.0.9 on a work project 
targeting net462 and, apart from having to perform some assembly rebinds to 
handle dependencies which expect log4net 2.0.8, it's working fine with an 
ado.net appender and a rolling log file appender, so I'd really like to know 
more about your environment & configuration.
 
-d
 

RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

[Davyd McColl]

Have you tried an assembly rebind to force resolution to 2.0.9?

-d


On September 8, 2020 18:00:45 "Joseph A. MITOLA"  wrote:


Hi Davyd,

The weird thing is everything had been working fine with same 
configuration, framework version 4.6, etc. and all I did was update the 
nuget package for log4net from 2.0.8 to 2.0.9. After that IIS w3wp process 
along with perfmon.dll process on the deployment server crashed when the 
application was launched. No error logs were reported even when I set the 
internal debug to true, nothing. But then, if I revert the nuget package 
back to 2.0.8, everything is normal again including the logs with the 
internal debugging turned on. So, it makes me think that maybe the 2.0.9 
version is missing a dependency library or something but I couldn't find 
anything online to that effect.


Here is my config, I'm using RollingFileAppender, AdoNetAppender, and 
SmtpAppender



  
    value="C:/logs/contentapps-proxy_%date{MMdd}.log" />

    
    
    
    
    
    
    
  

    
    
  
  type="ContentAppsProxy.Filters.CustomAdoNetAppender">

    
    value="System.Data.Entity.Infrastructure.SqlConnectionFactory, 
EntityFramework" />
    

    
  
  
  
    
    
  
  
  
  
    
  
    
    
  
  
  
  
    
  
    
    
  
  
  
  
    
  
    
    
  
  
  
      
    
  
    
    
  
  
  
  
    
  
  type="ContentAppsProxy.Filters.CustomSmtpAppender">

    
    
    
  
    
    
  
    
    
  
 
  
    
    
    
    
  


Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu

From: Davyd McColl
Sent: Tuesday, September 8, 2020 12:08 AM
To: jmit...@berkeley.edu
Cc: dev@logging.apache.org
Subject: RE: issues with log4net 2.0.9 under IIS for projects using .net 
framework 4.5+


Hi Joseph

I've performed a (rather belated) upgrade to log4net 2.0.9 on a work 
project targeting net462 and, apart from having to perform some assembly 
rebinds to handle dependencies which expect log4net 2.0.8, it's working 
fine with an ado.net appender and a rolling log file appender, so I'd 
really like to know more about your environment & configuration.


-d