Interesting. Anyways, as there are workarounds, it’s not a release blocker at least.
On Sun, Oct 18, 2020 at 23:14 Davyd McColl <dav...@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 <boa...@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 <dav...@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 <boa...@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 <dav...@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 <boa...@gmail.com> >>>> >>> >> -- >> Matt Sicker <boa...@gmail.com> >> > -- Matt Sicker <boa...@gmail.com>
