It seems I forgot to add my +1 here. On Mon, 19 Oct 2020 at 01:45, Davyd McColl <dav...@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 <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
-- Matt Sicker <boa...@gmail.com>
