Zsh bugfixes released by RedHat

Zsh bugfixes released by RedHat

[Bart Schaefer]

https://rhn.redhat.com/errata/RHBA-2014-1806.html

Anybody know if these are new patches invented by RedHat,
or something they selectively picked up from our git?

I don't immediately recognize the descriptions in the errata.

Re: Zsh bugfixes released by RedHat

[Bart Schaefer]

On Nov 6,  9:13am, Ray Andrews wrote:
}
} Do people ever tinker with zsh on any level above the personal and not
} coordinate it with you guys?  Wouldn't that end up creating quite a mess?

Some of the OS packagers will roll patches for things that break their
specific system tests into their pre-compiled packages without telling
us directly, yes.  Usually though it's some patch we've already done
that they're just backporting to an older version that they consider
stable.

} Shouldn't they at least offer a patch to you so that it might become
} official everywhere?  It seems both rude and irresponsible.

Technically they are supposed to offer the patch to us, although zsh's
license is not as clingy that way as the GNU license for example.  In
RedHat's case the patches are probably in the .src.rpm bundle and we
could download and extract them if we wanted, I'm just trying to avoid
going through that if someone else already knows what's going on.

Re: Zsh bugfixes released by RedHat

[Jérémie Roquet]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

2014-11-06 16:56 GMT+01:00 Bart Schaefer <schaefer@brasslantern.com>:
> https://rhn.redhat.com/errata/RHBA-2014-1806.html
>
> Anybody know if these are new patches invented by RedHat,
> or something they selectively picked up from our git?
>
> I don't immediately recognize the descriptions in the errata.

The syntax fix is a combination of commit
8879c46a4897a0e347455334fc6b6732c203a220 and commit
9a044f1a6ad4ecfdfeff2f89e1685a1d622cb029, both in git.

The malloc workaround is attached and *not* in git. Its name suggests
it's only a workaround, maybe the reason no patch was sent upstream?

Best regards,

-- 
Jérémie

[-- Attachment #2: BZ-978613-malloc-from-signal-handler-workaround.patch --]
[-- Type: text/x-patch, Size: 389 bytes --]

--- zsh-4.3.10/Src/exec.c.open  2009-03-16 23:57:07.000000000 +0530
+++ zsh-4.3.10/Src/exec.c       2014-04-09 19:41:25.829453955 +0530
@@ -4080,7 +4080,9 @@ execshfunc(Shfunc shf, LinkList args)
        sfcontext = SFC_DIRECT;
     doshfunc(shf, args, 0);
     sfcontext = osfc;
+    queue_signals();
     free(cmdstack);
+    unqueue_signals(); 
     cmdstack = ocs;
     cmdsp = ocsp;

Re: Zsh bugfixes released by RedHat

[Christian Neukirchen]

Bart Schaefer <schaefer@brasslantern.com> writes:

> https://rhn.redhat.com/errata/RHBA-2014-1806.html
>
> Anybody know if these are new patches invented by RedHat,
> or something they selectively picked up from our git?
>
> I don't immediately recognize the descriptions in the errata.

Afaics (from
http://vault.centos.org/6.6/updates/Source/SPackages/zsh-4.3.10-9.el6.src.rpm
), the patches are:

# RHEL-6.6
Patch22: BZ-859859-syntax-check-fail.patch
Patch23: BZ-978613-malloc-from-signal-handler-workaround.patch

Where the former is #31851 + #31846, and the latter is not in zsh HEAD:

\f
--- zsh-4.3.10/Src/exec.c.open  2009-03-16 23:57:07.000000000 +0530
+++ zsh-4.3.10/Src/exec.c       2014-04-09 19:41:25.829453955 +0530
@@ -4080,7 +4080,9 @@ execshfunc(Shfunc shf, LinkList args)
        sfcontext = SFC_DIRECT;
     doshfunc(shf, args, 0);
     sfcontext = osfc;
+    queue_signals();
     free(cmdstack);
+    unqueue_signals(); 
     cmdstack = ocs;
     cmdsp = ocsp;
\f

Not sure why they sit 7 months on that...
-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: Zsh bugfixes released by RedHat

[Ray Andrews]

On 11/06/2014 07:56 AM, Bart Schaefer wrote:
> https://rhn.redhat.com/errata/RHBA-2014-1806.html
>
> Anybody know if these are new patches invented by RedHat,
> or something they selectively picked up from our git?
>
> I don't immediately recognize the descriptions in the errata.
>
Do people ever tinker with zsh on any level above the personal and not
coordinate it with you guys?  Wouldn't that end up creating quite a mess?
Shouldn't they at least offer a patch to you so that it might become
official everywhere?  It seems both rude and irresponsible. Or is that
sort of thing considered normal?

Re: Zsh bugfixes released by RedHat

[Bart Schaefer]

On Nov 6,  6:04pm, Christian Neukirchen wrote:
}
} Patch23: BZ-978613-malloc-from-signal-handler-workaround.patch

Thanks.  This patch actually doesn't make a lot of sense, because
free() is #define macro'd to zfree() which already contains calls
to do signal queueing around all the interesting parts.

If there really has been a signal problem discovered here, I think
the following is a more complete fix, as calling a signal handler
with cmdstack and cmpsp out of sync would be just as bad as calling
it within a malloc operation.


diff --git a/Src/exec.c b/Src/exec.c
index d2d4e80..042215d 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -4555,6 +4555,7 @@ execshfunc(Shfunc shf, LinkList args)
 	fputc('\n', xtrerr);
 	fflush(xtrerr);
     }
+    queue_signals();
     ocs = cmdstack;
     ocsp = cmdsp;
     cmdstack = (unsigned char *) zalloc(CMDSTACKSZ);
@@ -4562,7 +4563,11 @@ execshfunc(Shfunc shf, LinkList args)
     if ((osfc = sfcontext) == SFC_NONE)
 	sfcontext = SFC_DIRECT;
     xtrerr = stderr;
+    unqueue_signals();
+
     doshfunc(shf, args, 0);
+
+    queue_signals();
     sfcontext = osfc;
     free(cmdstack);
     cmdstack = ocs;
@@ -4570,6 +4575,7 @@ execshfunc(Shfunc shf, LinkList args)
 
     if (!list_pipe)
 	deletefilelist(last_file_list, 0);
+    unqueue_signals();
 }
 
 /*

Re: Zsh bugfixes released by RedHat

[Axel Beckert]

Hi,

On Thu, Nov 06, 2014 at 08:30:35AM -0800, Bart Schaefer wrote:
> } Shouldn't they at least offer a patch to you so that it might become
> } official everywhere?

I know of nearly no license requiring that. And if so, at least Debian
would consider such a license as non-free[1].

> Technically they are supposed to offer the patch to us, although zsh's
> license is not as clingy that way as the GNU license for example.

JFTR: The GNU General Public License does not require that any
modification made to software under the GNU GPL is sent back to the
_author_ of the software.

It only requires that those modifications are available to _users_ of
binary compilations based on those modifications. Those users can then
decide to forward those patches back to the original author, but
nobody is required to do that.

There are two common license checks (which the GNU GPL fulfills) which
show why it can be a bad idea to require modifications to be sent back
to the authors. Citing from [1]:

    The Desert Island test.

    Imagine a castaway on a desert island with a solar-powered
    computer. This would make it impossible to fulfill any requirement
    to make changes publicly available or to send patches to some
    particular place. This holds even if such requirements are only
    upon request, as the castaway might be able to receive messages
    but be unable to send them. To be free, software must be
    modifiable by this unfortunate castaway, who must also be able to
    legally share modifications with friends on the island.

    The Dissident test.

    Consider a dissident in a totalitarian state who wishes to share a
    modified bit of software with fellow dissidents, but does not wish
    to reveal the identity of the modifier, or directly reveal the
    modifications themselves, or even possession of the program, to
    the government. Any requirement for sending source modifications
    to anyone other than the recipient of the modified binary---in
    fact any forced distribution at all, beyond giving source to those
    who receive a copy of the binary---would put the dissident in
    danger. For Debian to consider software free it must not require
    any such "excess" distribution.

[1] https://people.debian.org/~bap/dfsg-faq.html#testing
    https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines#debian-legal_tests_for_DFSG_compliance

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Zsh bugfixes released by RedHat

[Bart Schaefer]

On Nov 6,  9:15pm, Axel Beckert wrote:
}
} > Technically they are supposed to offer the patch to us, although zsh's
} > license is not as clingy that way as the GNU license for example.
} 
} JFTR: The GNU General Public License does not require that any
} modification made to software under the GNU GPL is sent back to the
} _author_ of the software.

Right, I was being too non-specific when I used the word "us".  I meant
they should offer the patch to anyone to whom they offer the binary.
Since I'm getting the errata notice about the new binary, technically
I should have access to the patch.  Which I do, it's just a PITA to
download the entire .src.rpm and extract it.

But they're also not required to make it *easy* to get the patch ...

So thank you to the folks who did that for me, and hopefully RedHat
will see the change I just pushed and pick that up instead.

And also thanks to the Debian and other distribution folks who watch
this list and voluntarily send us back the diffs for bugs they find,
rather than making us dig them out of a package manager bundle.

Re: Zsh bugfixes released by RedHat

[Ray Andrews]

On 11/06/2014 12:15 PM, Axel Beckert wrote:
> } Shouldn't they at least offer a patch to you so that it might become
> } official everywhere?
> I know of nearly no license requiring that. And if so, at least Debian
> would consider such a license as non-free[1].
I wasn't considering it from the point of view of legal requirements, 
but just from the
point of view of good manners and sound practice.  Having various 
different editions of
zsh (or anything) floating around out there that may or may not be 
compatible seems
like a bad idea. (Strictly necessary 'local' compatibility issues for 
any given distro
being, as Bart said, an exception. )  I was just curious if that sort of 
thing happens
very often.  Seems to me very poor for Bart to stumble upon a RedHat 
supposed
bug fix that he doesn't even know about.  You might think they'd notify 
us. Just
wondering.

Re: Zsh bugfixes released by RedHat

[Christian Neukirchen]

Bart Schaefer <schaefer@brasslantern.com> writes:

> On Nov 6,  9:15pm, Axel Beckert wrote:
> }
> } > Technically they are supposed to offer the patch to us, although zsh's
> } > license is not as clingy that way as the GNU license for example.
> } 
> } JFTR: The GNU General Public License does not require that any
> } modification made to software under the GNU GPL is sent back to the
> } _author_ of the software.
>
> Right, I was being too non-specific when I used the word "us".  I meant
> they should offer the patch to anyone to whom they offer the binary.
> Since I'm getting the errata notice about the new binary, technically
> I should have access to the patch.  Which I do, it's just a PITA to
> download the entire .src.rpm and extract it.
>
> But they're also not required to make it *easy* to get the patch ...
>
> So thank you to the folks who did that for me, and hopefully RedHat
> will see the change I just pushed and pick that up instead.

Note that I took it from the CentOS repositories, because RedHat wont
distribute their patched zsh to me (neither in source nor binary form)!
(Yeah, I know, CentOS is a part of RedHat now.  Still.)

(I actually expected having to diff the source tree against a zsh
release, just like they used to with their Kernel tree.)

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: Zsh bugfixes released by RedHat

[Axel Beckert]

Hi,

On Thu, Nov 06, 2014 at 12:47:17PM -0800, Bart Schaefer wrote:
> On Nov 6,  9:15pm, Axel Beckert wrote:
> } > Technically they are supposed to offer the patch to us, although zsh's
> } > license is not as clingy that way as the GNU license for example.
> } 
> } JFTR: The GNU General Public License does not require that any
> } modification made to software under the GNU GPL is sent back to the
> } _author_ of the software.
> 
> Right, I was being too non-specific when I used the word "us". I meant
> they should offer the patch to anyone to whom they offer the binary.

Ah, ok. Yes.

> But they're also not required to make it *easy* to get the patch ...

*g*

> And also thanks to the Debian and other distribution folks who watch
> this list and voluntarily send us back the diffs for bugs they find,

You're welcome. :-)

> rather than making us dig them out of a package manager bundle.

>From our (Debian's zsh packaging team) point of view, it makes the
package maintenance easier as we don't have to keep track of many
patches, and if so, we can at least drop most of them with the next
zsh release: http://sources.debian.net/src/zsh/5.0.7-3/debian/patches/

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Zsh bugfixes released by RedHat

[Jérémie Roquet]

2014-11-06 23:10 GMT+01:00 Christian Neukirchen <chneukirchen@gmail.com>:
> Note that I took it from the CentOS repositories, because RedHat wont
> distribute their patched zsh to me (neither in source nor binary form)!
> (Yeah, I know, CentOS is a part of RedHat now.  Still.)

I suppose this is from RedHat, but I may be wrong :
http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/

-- 
Jérémie

Re: Zsh bugfixes released by RedHat

[Christian Neukirchen]

Jérémie Roquet <arkanosis@gmail.com> writes:

> 2014-11-06 23:10 GMT+01:00 Christian Neukirchen <chneukirchen@gmail.com>:
>> Note that I took it from the CentOS repositories, because RedHat wont
>> distribute their patched zsh to me (neither in source nor binary form)!
>> (Yeah, I know, CentOS is a part of RedHat now.  Still.)
>
> I suppose this is from RedHat, but I may be wrong :
> http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/

You are right.  I was confused by the line
"(The unlinked packages above are only available from the Red Hat Network)"

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org