Thanks Ralph
-d
On October 26, 2020 18:48:30 Ralph Goers <ralph.go...@dslextreme.com> wrote:
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>
