The files were added to the distribution directory. Ralph
> On Oct 26, 2020, at 9:22 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > OK > > +1 to these. > > Ralph > >> On Oct 26, 2020, at 8:57 AM, Davyd McColl <dav...@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 <dav...@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 <boa...@gmail.com> wrote: >>> >>>> 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> > > >
