Re: [LOG4NET] Vote for release: 2.0.12

2020-10-18 Thread Davyd McColl
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 

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-18 Thread Remko Popma
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

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-18 Thread Matt Sicker
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 lin

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-18 Thread Davyd McColl
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

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-18 Thread Remko Popma
+1 for the release. Remko. > On Oct 19, 2020, at 5:24, 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 > some

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-18 Thread Matt Sicker
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 th

Re: Log4j 2 Compile error

2020-10-18 Thread Ralph Goers
Yup. Changing the toolchain version from 9 to 11 fixed it. Ralph > On Oct 18, 2020, at 1:05 PM, Ralph Goers wrote: > > This looks like https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8193802 > . > > Ralph > >> On Oct 18, 2020

Re: Log4j 2 Compile error

2020-10-18 Thread Ralph Goers
This looks like https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8193802 . Ralph > On Oct 18, 2020, at 1:03 PM, Ralph Goers wrote: > > Shoot. I just recalled that log4j-perf is compiled with Java 9+. I will have > to check what

Re: Log4j 2 Compile error

2020-10-18 Thread Ralph Goers
Shoot. I just recalled that log4j-perf is compiled with Java 9+. I will have to check what is being used for that, but nothing has changed in ages. Ralph > On Oct 18, 2020, at 12:58 PM, Ralph Goers wrote: > > MacBook Pro with Catalina 10.15.6. failed with Oracle Java 8.144 and Corretto > 8.26

Re: Log4j 2 Compile error

2020-10-18 Thread Ralph Goers
MacBook Pro with Catalina 10.15.6. failed with Oracle Java 8.144 and Corretto 8.265. I’ve used 8.144 for a long time without any problems, including the last release. Ralph > On Oct 18, 2020, at 12:21 PM, Volkan Yazıcı wrote: > > Last GitHub Actions build on release-2.x looks okayish, i.e.,

Re: Log4j 2 Compile error

2020-10-18 Thread Volkan Yazıcı
Last GitHub Actions build on release-2.x looks okayish, i.e., nothing new besides already known failures: https://github.com/apache/logging-log4j2/actions/runs/292125976 Which OS, JDK(s)did you use? On Sun, 18 Oct 2020, 21:04 Ralph Goers wrote: > I just tried to do a full build for the first tim

Log4j 2 Compile error

2020-10-18 Thread Ralph Goers
I just tried to do a full build for the first time in a while and am getting [INFO] Compiling 77 source files to /Users/rgoers/projects/apache/logging/log4j/release-2.x/log4j-perf/target/classes [INFO] - [ERROR] COMPILATION ERROR : [INF

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-18 Thread Davyd McColl
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

Re: [LOG4NET] Vote for release: 2.0.12

2020-10-18 Thread Matt Sicker
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: Arch

[LOG4NET] Vote for release: 2.0.12

2020-10-18 Thread Davyd McColl
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 Platf