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] 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>
