* Bernhard Voelker (m...@bernhard-voelker.de) [20140710 10:27]:
> puh, for me as openSUSE user this means that I have to build
> gettext on my hosts, as the latest release openSUSE-13.1 still
> uses 0.18.3.1 (and most probably won't upgrade)
It will most definitely not be updated to a newer versi
Philipp Thomas writes:
> The number of packages that failed to build with 0.19.1 was too high
> to be acceptable and the person who did the update refused to resolve
> the problems with the the affected packages the update was rejected. I
> just requested the update again so let's see whether it
* Daiki Ueno (u...@gnu.org) [20140711 15:13]:
> Could you provide an example of the build failures with 0.19.1? Yes,
> 0.19 had such problems[1], but with 0.19.1 we haven't received any single
> bug report that affects building other packages, except this:
I'll send you ex
On 07/11/2014 03:13 PM, Daiki Ueno wrote:
Could you provide an example of the build failures with 0.19.1?
https://build.opensuse.org/package/live_build_log/Base:System/coreutils/openSUSE_Factory/i586
[ 172s] *** Error in `/usr/bin/xgettext': realloc(): invalid pointer:
0x098f4ea8 ***
[ 172s
Bernhard Voelker writes:
> On 07/11/2014 03:13 PM, Daiki Ueno wrote:
>> Could you provide an example of the build failures with 0.19.1?
>
> https://build.opensuse.org/package/live_build_log/Base:System/coreutils/openSUSE_Factory/i586
>
> [ 172s] *** Error in `/usr/bin/xgettext': realloc(): inval
On 07/11/2014 02:45 AM, Paul Eggert wrote:
Thanks, it seems to be a compiler bug on Ubuntu: "#pragma weak" doesn't work,
and this breaks gnulib's glthread module. For what it's worth I filed a bug report here:
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1340250
Are you expert
Fix by Andreas Schwab in:
https://sourceware.org/ml/libc-alpha/2014-06/msg00503.html
* lib/regcomp.c (parse_reg_exp): Deallocate partially
constructed tree before returning error.
---
ChangeLog | 8
lib/regcomp.c | 6 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git
On 07/08/2014 12:42 PM, Eric Blake wrote:
It is unclear
at this point whether POSIX would recommend that filter
applications should_always_ exit with 0 status on pipe failure,
or only do this for EPIPE write failures when SIGPIPE is ignored,
or whether it should be optional behavior that must be
On 07/11/2014 02:58 PM, Paul Eggert wrote:
> On 07/08/2014 12:42 PM, Eric Blake wrote:
>> It is unclear
>> at this point whether POSIX would recommend that filter
>> applications should_always_ exit with 0 status on pipe failure,
>> or only do this for EPIPE write failures when SIGPIPE is ignored,
On 07/11/2014 02:10 PM, Eric Blake wrote:
are you arguing that any shell that provides 'set -o pipefail' should
ALSO provide a knob to explicitly treat death due to SIGPIPE as not
impacting pipefail? At which point, then you DO want to re-enable
rather than ignore SIGPIPE, and don't have to worr
10 matches
Mail list logo
