[Dropping the Austin Group from the CCs, since Interix does not attempt
POSIX compliance.]
Jason Zions wrote:
> A few hundred thousand users of applications ported to that environment
> might disagree. Interix and the Vista/WS08 Subsystem for UNIX Applications
> do not include an sa_sigaction mem
Jason Zions wrote about Interix 3.5:
> Interix and the Vista/WS08 Subsystem for UNIX Applications do not include an
> sa_sigaction member, as you point out, but they don't claim to conform to
> the C Extensions or to IEEE Std 1003.1-2001.
Then, if the system does not claim to conform to POSIX, you
Paul Eggert wrote:
> I'd feel a bit safer if we wrote the code to conform to POSIX rather
> than assume the typical implementation where sa_handler and
> sa_sigaction overlap.
Sorry, I can't follow the argumentation. The set of systems where
sa_handler and sa_sigaction are disjoint is empty, and y
Bruno Haible <[EMAIL PROTECTED]> writes:
> if (sigaction (fatal_signals[i], NULL, &action) >= 0
> + /* POSIX says that SIG_IGN can only occur when action.sa_flags
> + does not contain SA_SIGINFO. But in Linux 2.4, for example,
> + SA_SIGINFO can actuall
() Bruno Haible <[EMAIL PROTECTED]>
() Thu, 19 Jun 2008 13:52:13 +0200
I couldn't apply it like this, however, because you cannot have rule
dependencies with wildcards like this:
update-stamp: *.texi */*.texi
Ok, will keep in mind for the next time.
I applied these two patches.
() Simon Josefsson <[EMAIL PROTECTED]>
() Thu, 19 Jun 2008 12:51:14 +0200
You could push your fork to some git host like repo.or.cz, or setup
gitweb on your own site, although it doesn't strike me as ideal (what if
everyone creates their own gnulib fork on repo.or.cz?).
If a lightweight-
Thien-Thi Nguyen wrote:
> Zonking a CVS-ism in gnulib documentation...
Thank you for the patch.
I couldn't apply it like this, however, because you cannot have rule
dependencies with wildcards like this:
update-stamp: *.texi */*.texi
You need to use the GNU make function $(wildcard ...) for
Thien-Thi Nguyen <[EMAIL PROTECTED]> writes:
>Of course, it is better to merge your changes into the real
>gnulib. If you've noticed a real problem, report that and it
>would hopefully be fixed.
>
> Yes, that is what i want to do. At the moment, to do so means:
>
> - identify problem
() Simon Josefsson <[EMAIL PROTECTED]>
() Thu, 19 Jun 2008 11:06:04 +0200
> BTW, what is the prevailing advice if i want to publish a git
> repo containing only diffs between upstream gnulib my
> branches? The goal is to make these branches available w/
> minimal space/bandwidth cost.
Thien-Thi Nguyen <[EMAIL PROTECTED]> writes:
> BTW, what is the prevailing advice if i want to publish a git repo
> containing only diffs between upstream gnulib my branches? The goal is
> to make these branches available w/ minimal space/bandwidth cost.
Do you really need to fork gnulib to do t
Zonking a CVS-ism in gnulib documentation...
BTW, what is the prevailing advice if i want to publish a git repo
containing only diffs between upstream gnulib my branches? The goal is
to make these branches available w/ minimal space/bandwidth cost.
thi
__
11 matches
Mail list logo
