You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Davyd McColl <da...@gmail.com> on 2020/10/18 16:02:40 UTC
[LOG4NET] Vote for release: 2.0.12
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: [LOG4NET] Vote for release: 2.0.12
Posted by Remko Popma <re...@gmail.com>.
+1 for the release.
Remko.
> On Oct 19, 2020, at 5:24, Matt Sicker <bo...@gmail.com> 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 <da...@gmail.com> 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 <bo...@gmail.com> 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 <da...@gmail.com> 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 <bo...@gmail.com>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] Vote for release: 2.0.12
Posted by Davyd McColl <da...@gmail.com>.
Thanks Ralph
-d
On October 26, 2020 18:48:30 Ralph Goers <ra...@dslextreme.com> wrote:
> The files were added to the distribution directory.
>
> Ralph
>
>> On Oct 26, 2020, at 9:22 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> OK
>>
>> +1 to these.
>>
>> Ralph
>>
>>> On Oct 26, 2020, at 8:57 AM, Davyd McColl <da...@gmail.com> wrote:
>>>
>>> Ralph, here's the 2.0.12 thread where Matt and Remko voted.
>>>
>>> -d
>>>
>>>
>>> On October 23, 2020 17:57:31 Davyd McColl <da...@gmail.com> wrote:
>>>
>>>> Thanks Matt
>>>>
>>>> I think I need 3 to release... Any other takers?
>>>>
>>>> -d
>>>>
>>>>
>>>> On October 23, 2020 17:33:19 Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>>> It seems I forgot to add my +1 here.
>>>>>
>>>>> On Mon, 19 Oct 2020 at 01:45, Davyd McColl <da...@gmail.com> 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 <re...@gmail.com> 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 server, so please could you do so
>>>>>> for me?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for your time
>>>>>>>>>>>> -d
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker
>>>>>>>>>
>>>>>>>> --
>>>>>>> Matt Sicker
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
Re: [LOG4NET] Vote for release: 2.0.12
Posted by Ralph Goers <ra...@dslextreme.com>.
The files were added to the distribution directory.
Ralph
> On Oct 26, 2020, at 9:22 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> OK
>
> +1 to these.
>
> Ralph
>
>> On Oct 26, 2020, at 8:57 AM, Davyd McColl <da...@gmail.com> wrote:
>>
>> Ralph, here's the 2.0.12 thread where Matt and Remko voted.
>>
>> -d
>>
>>
>> On October 23, 2020 17:57:31 Davyd McColl <da...@gmail.com> wrote:
>>
>>> Thanks Matt
>>>
>>> I think I need 3 to release... Any other takers?
>>>
>>> -d
>>>
>>>
>>> On October 23, 2020 17:33:19 Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> It seems I forgot to add my +1 here.
>>>>
>>>> On Mon, 19 Oct 2020 at 01:45, Davyd McColl <da...@gmail.com> 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 <re...@gmail.com> 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 server, so please could you do so
>>>>> for me?
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your time
>>>>>>>>>>> -d
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker
>>>>>>>>
>>>>>>> --
>>>>>> Matt Sicker
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>
>
>
Re: [LOG4NET] Vote for release: 2.0.12
Posted by Ralph Goers <ra...@dslextreme.com>.
OK
+1 to these.
Ralph
> On Oct 26, 2020, at 8:57 AM, Davyd McColl <da...@gmail.com> wrote:
>
> Ralph, here's the 2.0.12 thread where Matt and Remko voted.
>
> -d
>
>
> On October 23, 2020 17:57:31 Davyd McColl <da...@gmail.com> wrote:
>
>> Thanks Matt
>>
>> I think I need 3 to release... Any other takers?
>>
>> -d
>>
>>
>> On October 23, 2020 17:33:19 Matt Sicker <bo...@gmail.com> wrote:
>>
>>> It seems I forgot to add my +1 here.
>>>
>>> On Mon, 19 Oct 2020 at 01:45, Davyd McColl <da...@gmail.com> 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 <re...@gmail.com> 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 server, so please could you do so
>>>> for me?
>>>> >>>>>>
>>>> >>>>>> Thanks for your time
>>>> >>>>>> -d
>>>> >>>>>>
>>>> >>>>> --
>>>> >>>>> Matt Sicker
>>>> >>>>>
>>>> >>>>
>>>> >>> --
>>>> >>> Matt Sicker
>>>> >>>
>>>> >> --
>>>> > Matt Sicker
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] Vote for release: 2.0.12
Posted by Davyd McColl <da...@gmail.com>.
Ralph, here's the 2.0.12 thread where Matt and Remko voted.
-d
On October 23, 2020 17:57:31 Davyd McColl <da...@gmail.com> wrote:
> Thanks Matt
>
> I think I need 3 to release... Any other takers?
>
> -d
>
>
> On October 23, 2020 17:33:19 Matt Sicker <bo...@gmail.com> wrote:
>
>> It seems I forgot to add my +1 here.
>>
>> On Mon, 19 Oct 2020 at 01:45, Davyd McColl <da...@gmail.com> 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 <re...@gmail.com> 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 server, so please could you do so
>>> for me?
>>> >>>>>>
>>> >>>>>> Thanks for your time
>>> >>>>>> -d
>>> >>>>>>
>>> >>>>> --
>>> >>>>> Matt Sicker
>>> >>>>>
>>> >>>>
>>> >>> --
>>> >>> Matt Sicker
>>> >>>
>>> >> --
>>> > Matt Sicker
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] Vote for release: 2.0.12
Posted by Davyd McColl <da...@gmail.com>.
Thanks Matt
I think I need 3 to release... Any other takers?
-d
On October 23, 2020 17:33:19 Matt Sicker <bo...@gmail.com> wrote:
> It seems I forgot to add my +1 here.
>
> On Mon, 19 Oct 2020 at 01:45, Davyd McColl <da...@gmail.com> 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 <re...@gmail.com> 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 server, so please could you do so
>> for me?
>> >>>>>>
>> >>>>>> Thanks for your time
>> >>>>>> -d
>> >>>>>>
>> >>>>> --
>> >>>>> Matt Sicker
>> >>>>>
>> >>>>
>> >>> --
>> >>> Matt Sicker
>> >>>
>> >> --
>> > Matt Sicker
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] Vote for release: 2.0.12
Posted by Matt Sicker <bo...@gmail.com>.
It seems I forgot to add my +1 here.
On Mon, 19 Oct 2020 at 01:45, Davyd McColl <da...@gmail.com> 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 <re...@gmail.com> 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 server, so please could you do so for me?
> >>>>>>
> >>>>>> Thanks for your time
> >>>>>> -d
> >>>>>>
> >>>>> --
> >>>>> Matt Sicker
> >>>>>
> >>>>
> >>> --
> >>> Matt Sicker
> >>>
> >> --
> > Matt Sicker
--
Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] Vote for release: 2.0.12
Posted by Davyd McColl <da...@gmail.com>.
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 <re...@gmail.com> 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 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
Posted by Remko Popma <re...@gmail.com>.
Is this not a vote thread?
> On Oct 19, 2020, at 13:27, Matt Sicker <bo...@gmail.com> 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 <da...@gmail.com> 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 <bo...@gmail.com> 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 <da...@gmail.com> 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 <bo...@gmail.com> 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 <da...@gmail.com> 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]
>>>>>> <https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12%5D>
>>>>>> 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 <bo...@gmail.com>
>>>>>
>>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>> --
> Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] Vote for release: 2.0.12
Posted by Matt Sicker <bo...@gmail.com>.
Interesting. Anyways, as there are workarounds, it’s not a release blocker
at least.
On Sun, Oct 18, 2020 at 23:14 Davyd McColl <da...@gmail.com> 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 <bo...@gmail.com> 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 <da...@gmail.com> 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 <bo...@gmail.com> 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 <da...@gmail.com> 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]
>>>>> <https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12%5D>
>>>>> 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 <bo...@gmail.com>
>>>>
>>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
> --
Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] Vote for release: 2.0.12
Posted by Davyd McColl <da...@gmail.com>.
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 <bo...@gmail.com> 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 <da...@gmail.com> 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 <bo...@gmail.com> 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 <da...@gmail.com> 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 <bo...@gmail.com>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] Vote for release: 2.0.12
Posted by Matt Sicker <bo...@gmail.com>.
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 <da...@gmail.com> 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 <bo...@gmail.com> 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 <da...@gmail.com> 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 <bo...@gmail.com>
--
Matt Sicker <bo...@gmail.com>
Re: [LOG4NET] Vote for release: 2.0.12
Posted by Davyd McColl <da...@gmail.com>.
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 <bo...@gmail.com> 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 <da...@gmail.com> 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 <bo...@gmail.com>
Re: [LOG4NET] Vote for release: 2.0.12
Posted by Matt Sicker <bo...@gmail.com>.
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 <da...@gmail.com> 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 <bo...@gmail.com>