* Zsh bugfixes released by RedHat
@ 2014-11-06 15:56 Bart Schaefer
2014-11-06 16:58 ` Jérémie Roquet
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Bart Schaefer @ 2014-11-06 15:56 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Zsh bugfixes released by RedHat
2014-11-06 17:13 ` Ray Andrews
@ 2014-11-06 16:30 ` Bart Schaefer
2014-11-06 20:15 ` Axel Beckert
0 siblings, 1 reply; 13+ messages in thread
From: Bart Schaefer @ 2014-11-06 16:30 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Zsh bugfixes released by RedHat
2014-11-06 15:56 Zsh bugfixes released by RedHat Bart Schaefer
@ 2014-11-06 16:58 ` Jérémie Roquet
2014-11-06 17:04 ` Christian Neukirchen
2014-11-06 17:13 ` Ray Andrews
2 siblings, 0 replies; 13+ messages in thread
From: Jérémie Roquet @ 2014-11-06 16:58 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Zsh Hackers' List
[-- 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;
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Zsh bugfixes released by RedHat
2014-11-06 15:56 Zsh bugfixes released by RedHat Bart Schaefer
2014-11-06 16:58 ` Jérémie Roquet
@ 2014-11-06 17:04 ` Christian Neukirchen
2014-11-06 18:40 ` Bart Schaefer
2014-11-06 17:13 ` Ray Andrews
2 siblings, 1 reply; 13+ messages in thread
From: Christian Neukirchen @ 2014-11-06 17:04 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Zsh bugfixes released by RedHat
2014-11-06 15:56 Zsh bugfixes released by RedHat Bart Schaefer
2014-11-06 16:58 ` Jérémie Roquet
2014-11-06 17:04 ` Christian Neukirchen
@ 2014-11-06 17:13 ` Ray Andrews
2014-11-06 16:30 ` Bart Schaefer
2 siblings, 1 reply; 13+ messages in thread
From: Ray Andrews @ 2014-11-06 17:13 UTC (permalink / raw)
To: zsh-workers
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Zsh bugfixes released by RedHat
2014-11-06 17:04 ` Christian Neukirchen
@ 2014-11-06 18:40 ` Bart Schaefer
0 siblings, 0 replies; 13+ messages in thread
From: Bart Schaefer @ 2014-11-06 18:40 UTC (permalink / raw)
To: zsh-workers
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();
}
/*
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Zsh bugfixes released by RedHat
2014-11-06 16:30 ` Bart Schaefer
@ 2014-11-06 20:15 ` Axel Beckert
2014-11-06 20:47 ` Bart Schaefer
2014-11-06 21:57 ` Ray Andrews
0 siblings, 2 replies; 13+ messages in thread
From: Axel Beckert @ 2014-11-06 20:15 UTC (permalink / raw)
To: zsh-workers
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)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Zsh bugfixes released by RedHat
2014-11-06 20:15 ` Axel Beckert
@ 2014-11-06 20:47 ` Bart Schaefer
2014-11-06 22:10 ` Christian Neukirchen
2014-11-06 22:10 ` Axel Beckert
2014-11-06 21:57 ` Ray Andrews
1 sibling, 2 replies; 13+ messages in thread
From: Bart Schaefer @ 2014-11-06 20:47 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Zsh bugfixes released by RedHat
2014-11-06 20:15 ` Axel Beckert
2014-11-06 20:47 ` Bart Schaefer
@ 2014-11-06 21:57 ` Ray Andrews
1 sibling, 0 replies; 13+ messages in thread
From: Ray Andrews @ 2014-11-06 21:57 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Zsh bugfixes released by RedHat
2014-11-06 20:47 ` Bart Schaefer
@ 2014-11-06 22:10 ` Christian Neukirchen
2014-11-06 22:21 ` Jérémie Roquet
2014-11-06 22:10 ` Axel Beckert
1 sibling, 1 reply; 13+ messages in thread
From: Christian Neukirchen @ 2014-11-06 22:10 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Zsh bugfixes released by RedHat
2014-11-06 20:47 ` Bart Schaefer
2014-11-06 22:10 ` Christian Neukirchen
@ 2014-11-06 22:10 ` Axel Beckert
1 sibling, 0 replies; 13+ messages in thread
From: Axel Beckert @ 2014-11-06 22:10 UTC (permalink / raw)
To: zsh-workers
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)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Zsh bugfixes released by RedHat
2014-11-06 22:10 ` Christian Neukirchen
@ 2014-11-06 22:21 ` Jérémie Roquet
2014-11-07 15:06 ` Christian Neukirchen
0 siblings, 1 reply; 13+ messages in thread
From: Jérémie Roquet @ 2014-11-06 22:21 UTC (permalink / raw)
To: Christian Neukirchen; +Cc: Zsh Hackers' List
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Zsh bugfixes released by RedHat
2014-11-06 22:21 ` Jérémie Roquet
@ 2014-11-07 15:06 ` Christian Neukirchen
0 siblings, 0 replies; 13+ messages in thread
From: Christian Neukirchen @ 2014-11-07 15:06 UTC (permalink / raw)
To: Jérémie Roquet; +Cc: Zsh Hackers' List
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-11-07 15:06 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-06 15:56 Zsh bugfixes released by RedHat Bart Schaefer
2014-11-06 16:58 ` Jérémie Roquet
2014-11-06 17:04 ` Christian Neukirchen
2014-11-06 18:40 ` Bart Schaefer
2014-11-06 17:13 ` Ray Andrews
2014-11-06 16:30 ` Bart Schaefer
2014-11-06 20:15 ` Axel Beckert
2014-11-06 20:47 ` Bart Schaefer
2014-11-06 22:10 ` Christian Neukirchen
2014-11-06 22:21 ` Jérémie Roquet
2014-11-07 15:06 ` Christian Neukirchen
2014-11-06 22:10 ` Axel Beckert
2014-11-06 21:57 ` Ray Andrews
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).