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 <remko.po...@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
