+1 for the release. Remko.
> On Oct 19, 2020, at 5:24, Matt Sicker <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > > -- > Matt Sicker <[email protected]>
