Re: [bug #21455] date --date "" "+test" fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

Philip Rowlands wrote: > I hacked up the following to avoid resetting my system clock all over > the place: I have found the FakeTime Preload Library to be very useful for these things. Let me recommend it as an alternative to setting the system time. Perhaps you will find it useful too. htt

Re: Errors in the coreutils-6.9 PO file

(Sorry for breaking thread, I'm not subscribed.) Jim Meyering wrote: > Clytie Siddall <[EMAIL PROTECTED]> wrote: > > 1. This is a fatal error for msgfmt: > > > > #: src/expr.c:133 > > #, c-format > > msgid "" > > "\n" > > " ARG1 * ARG2 arithmetic product of ARG1 and ARG2\n" > > " ARG1 / A

Re: [bug #21455] date --date "" "+test" fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

On Mon, 29 Oct 2007, Mischa Molhoek wrote: ok, here is the text version, because the image is remove by accident :) It's simpler to debug problems reported by text, not pictures. [titan: mischa] ~> date --version date (GNU coreutils) 5.97 Copyright (C) 2006 Free Software Foundation, Inc. Thi

Re: [bug #21459] Remove obsolete translation

savannahpwd <[EMAIL PROTECTED]> wrote: > Follow-up Comment #2, bug #21459 (project coreutils): > > It seems like all no.po files are gone from translationproject.org/latest at > least. Anything else I have to do to get the ball rolling? Oh! I've just checked, and see it's been fixed for some time.

[bug #21459] Remove obsolete translation

Follow-up Comment #2, bug #21459 (project coreutils): It seems like all no.po files are gone from translationproject.org/latest at least. Anything else I have to do to get the ball rolling? ___ Reply to this item at:

Re: [bug #21459] Remove obsolete translation

Bruno Haible <[EMAIL PROTECTED]> wrote: > Follow-up Comment #1, bug #21459 (project coreutils): > > I agree. The switch from no to nb was done in 2003. The gettext > users were informed about it in January 2004. That's more than > 3.5 years ago. > > But you should first have the TP remove the 'no'

[bug #21459] Remove obsolete translation

Follow-up Comment #1, bug #21459 (project coreutils): I agree. The switch from no to nb was done in 2003. The gettext users were informed about it in January 2004. That's more than 3.5 years ago. But you should first have the TP remove the 'no' translations, before the coreutils maintainers take

[bug #21455] date --date "" "+test" fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

Follow-up Comment #1, bug #21455 (project coreutils): ok, here is the text version, because the image is remove by accident :) [titan: mischa] ~> date --version date (GNU coreutils) 5.97 Copyright (C) 2006 Free Software Foundation, Inc. This is free software. You may redistribute copies of it

Re: FAIL: seq.log

The test is just bogus. You cannot assume that 10.95 can be represented exactly in floating point. Since 10.95 is exactly halfway between 10.9 and 11.0 both representations are equally valid, depending on the precision of the underlying floating point format. Andreas. -- Andreas Schwab, SuSE L

[bug #21459] Remove obsolete translation

URL: Summary: Remove obsolete translation Project: GNU Core Utilities Submitted by: kmaraas Submitted on: Monday 10/29/2007 at 09:55 Category: None Severity: 3 - Norma

[bug #21455] date --date "" "+test" fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

URL: Summary: date --date "" "+test" fails ONLY WITHIN CERTAIN TIME PERIOD #$%^% Project: GNU Core Utilities Submitted by: mischamolhoek Submitted on: Monday 10/29/2007 at 09:24 Categ

Re: escape sequences in test output -- colors (new snapshot)

[EMAIL PROTECTED] (Bob Proulx) wrote: > Jim Meyering wrote: >> Or just determine why the test for whether to enable colors >> isn't working for the buildbot? In build-aux/check.mk, it does this: >> >> if test -t 1; then >> red=... > > The 'test -t 1' does not check the value of TERM. It si

Re: escape sequences in test output -- colors (new snapshot)

Jim Meyering wrote: > Or just determine why the test for whether to enable colors > isn't working for the buildbot? In build-aux/check.mk, it does this: > > if test -t 1; then > red=... The 'test -t 1' does not check the value of TERM. It simply assumes a vt220 terminal and assigns escape

Re: FAIL: seq.log

Andreas Schwab <[EMAIL PROTECTED]> wrote: > $ cat seq.log > FAIL: seq.log (exit: 1) > === > > -: test float-3: stdout mismatch, comparing float-3.O (actual) and float-3.1 > (expected) > *** float-3.O Sun Oct 28 23:10:36 2007 > --- float-3.1 Sun Oct 28 23:10:36 2007 > **