Re: [LOG4NET] Vote for release: 2.0.12

2020-10-26 Thread 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 before I can push the

nupkg

to nuget.org, which is how most people will consume it.

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-26 Thread Ralph Goers 
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

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-26 Thread Ralph Goers 
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

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-26 Thread 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
>>
>> 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.

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-23 Thread 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-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

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-23 Thread Matt Sicker 
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]
> >>
>

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-19 Thread 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
>> 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

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-19 Thread Remko Popma 
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 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 
>>> 
>> --
> Matt Sicker

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-18 Thread Matt Sicker 
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 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 
>>
> --
Matt Sicker

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-18 Thread 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

2020-10-18 Thread Remko Popma 
+1 for the release.
Remko.



> On Oct 19, 2020, at 5:24, 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

2020-10-18 Thread Matt Sicker 
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

2020-10-18 Thread 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

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-18 Thread Matt Sicker 
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

2020-10-18 Thread 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