Thanks Ralph
-d
On October 26, 2020 18:48:30 Ralph Goers wrote:
The files were added to the distribution directory.
Ralph
On Oct 26, 2020, at 9:22 AM, Ralph Goers wrote:
OK
+1 to these.
Ralph
On Oct 26, 2020, at 8:57 AM, Davyd McColl wrote:
Ralph, here's the 2.0.12 thread where
The files were added to the distribution directory.
Ralph
> On Oct 26, 2020, at 9:22 AM, Ralph Goers wrote:
>
> OK
>
> +1 to these.
>
> Ralph
>
>> On Oct 26, 2020, at 8:57 AM, Davyd McColl wrote:
>>
>> Ralph, here's the 2.0.12 thread where Matt and Remko voted.
>>
>> -d
>>
>>
>> On
OK
+1 to these.
Ralph
> On Oct 26, 2020, at 8:57 AM, Davyd McColl wrote:
>
> Ralph, here's the 2.0.12 thread where Matt and Remko voted.
>
> -d
>
>
> On October 23, 2020 17:57:31 Davyd McColl wrote:
>
>> Thanks Matt
>>
>> I think I need 3 to release... Any other takers?
>>
>> -d
>>
>>
Ralph, here's the 2.0.12 thread where Matt and Remko voted.
-d
On October 23, 2020 17:57:31 Davyd McColl wrote:
Thanks Matt
I think I need 3 to release... Any other takers?
-d
On October 23, 2020 17:33:19 Matt Sicker wrote:
It seems I forgot to add my +1 here.
On Mon, 19 Oct 2020 at
Thanks Matt
I think I need 3 to release... Any other takers?
-d
On October 23, 2020 17:33:19 Matt Sicker wrote:
It seems I forgot to add my +1 here.
On Mon, 19 Oct 2020 at 01:45, Davyd McColl wrote:
Hi Remko
Yes, this is a vote thread -- thanks for your +1 (:
Matt, I've fortunately
It seems I forgot to add my +1 here.
On Mon, 19 Oct 2020 at 01:45, Davyd McColl 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
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
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,
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
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,
+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
>
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
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
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:
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
15 matches
Mail list logo
