On Thu, Feb 07, 2019 at 10:21:49PM +0100, Ansgar wrote:
(And you get 24-hour time, but very strange Endian in C.UTF-8:
WEEKDAY MMM DD HH:MM:SS TZ
while en_US.UTF-8 has at least DD MMM ... Having
-MM-DD HH:MM:SS[+]
instead would be much nicer if we were to create an arbitrary
Per the standard, the C locale is supposed to be a synonym for the POSIX
locale. Can someone give a quick explanation for why in debian the C
locale definition is 162k and the POSIX locale is 8k? Shouldn't they be
identical?
On Thu, Feb 07, 2019 at 04:08:21PM +0100, Ansgar wrote:
On Thu, 2019-02-07 at 09:59 -0500, Michael Stone wrote:
On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote:
> How would this locale differ from C.UTF-8? Is the only difference
> that C.UTF-8 has strict lexicographical s
On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote:
How would this locale differ from C.UTF-8? Is the only difference
that C.UTF-8 has strict lexicographical sorting, whereas "en" would have
case-insensitive sorting like en_GB.utf8 does? (If that's the only
difference, then perhaps
On Wed, Sep 28, 2016 at 09:03:38PM -0700, Richard Laager wrote:
Getting back to ZFS and /etc/hostid... I would think that a
randomly-generated /etc/hostid is probably sufficient. Whether that's
done in the libc, spl, or zfs package makes no difference to me.
You still haven't explained why zfs
On Wed, Sep 28, 2016 at 11:11:21PM +0200, Petter Reinholdtsen wrote:
[Michael Stone]
Other platforms have deprecated gethostid, that's the best way forward for
linux, IMO.
Which platforms is this? I find FreeBSD recommend to use sysctl and
KERN_HOSTID to get the hostid integer directly from
On Wed, Sep 28, 2016 at 12:32:04PM +0200, Florian Weimer wrote:
* Petter Reinholdtsen:
Something like this should work, I guess:
if [ ! -f /etc/hostid ]; then
if [ -e /sys/class/dmi/id/product_uuid ]; then
sethostidfromuuid $(cat /sys/class/dmi/id/product_uuid)
else
dd
This does not feel like a coreutils bug. Is it still reproducible?
Mike Stone
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Package: eglibc
Version: 2.10.1-7
Severity: important
Tags: patch
NSS plugins wishing to provide data to programs calling getaddrinfo() must
implement two procedures named:
_nss_foo_gethostbyname4_r() and
_nss_foo_gethostbyname2_r().
The function gaih_inet() in libc dynamically loads
On Tue, Feb 17, 2009 at 07:02:34PM +, Richard Kettlewell wrote:
Michael Stone wrote:
On Tue, Feb 17, 2009 at 06:35:54PM +, Richard Kettlewell wrote:
Michael Stone wrote:
Can someone having this problem please send uname -a output and
maybe an strace of a failed run? And the libc6
Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460689 and
let me know if I'm missing something. Basically, when sort is run on a
file with really long lines there are some mmaps that fail with ENOMEM,
and the program segfaults. But AFAIK, the mmaps are happening within the
Package: libc6.1
Severity: important
http://buildd.debian.org/fetch.php?pkg=coreutilsver=5.94-1arch=ia64stamp=1141336896file=logas=raw
From the build log:
pwd: ../sysdeps/unix/sysv/linux/getcwd.c:130: __getcwd: Assertion `__libc_errno
!= 34 || buf != ((void *)0) || size != 0' failed.
pwd:
On Tue, Jan 24, 2006 at 05:00:09PM +0100, Ludovic Drolez wrote:
I think that this bug (#343140) could also be a security problem.
No, it's not. Let the bug live or die on its own merits without waving
the security flag.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Package: libc6.1-dev
Version: 2.3.5-8
Severity: important
This should maybe be assigned to a different package, please reassign as
appropriate. Set to important because the bug is breaking the coreutils
build.
The test suite for coreutils has been failing on ia64 (only) with the
following
Any thoughts on this?
On Wed, Nov 23, 2005 at 09:19:25PM -0500, Michael Stone wrote:
Any thoughts on why coreutils is failing on (only) ia64 buildd?
http://buildd.debian.org/fetch.php?pkg=coreutilsver=5.93-5arch=ia64stamp=1132768587file=logas=raw
Looks to me like a bug in libc -- pwd
On Mon, Sep 27, 2004 at 08:47:04AM +0900, GOTO Masanori wrote:
You argument is no sense for me without code.
That's ridiculous. You can agree or disagree in principle without code.
I can't believe that anyone would waste time coding when you seem so
unwilling to consider changes.
Mike Stone
On Sat, Sep 25, 2004 at 11:26:36AM +0200, martin f krafft wrote:
Oh, whatever. I am not going to search whether this is specified in
the standards. I am talking about common sense here. A line such as
Tue Sep 14 06:19:23 Croatia/Split 2004
is just plain wrong. Either date should report an error
On Tue, Aug 31, 2004 at 12:26:28PM +0200, you wrote:
A) Using the same quotes as in english, i.e.,
Once again, the english quotes are also stupid:
mv -iv foo bar
`foo' - `bar'
It is not clear why german users are the only ones who need an apology
because they get stupid-looking quotes.
On Tue, Aug 31, 2004 at 04:59:05PM +0200, Mario Lang wrote:
Michael Stone [EMAIL PROTECTED] writes:
Once again, the english quotes are also stupid:
mv -iv foo bar
`foo' - `bar'
It is not clear why german users are the only ones who need an apology
because they get stupid-looking quotes
On Tue, Aug 31, 2004 at 08:28:14PM +0200, Mario Lang wrote:
It feels to me as if you are intentionally failing to get my point.
Likewise. :)
I have no problems reading ``this'' as double quotes, but ,,this is just
a double comma.
Well, `` isn't a double quote any more than ,, is--it's a pair of
On Tue, Aug 31, 2004 at 12:35:58PM -0700, Thomas Bushnell BSG wrote:
No apology is necessary, because of (1).
No apology is necessary because it's a ridiculous concept.
I hesitate to tell people to use UTF-8 because full multibyte compliance
isn't guaranteed in sarge.
Mike Stone
--
To UNSUBSCRIBE,
multibyte compliance
isn't guaranteed in sarge.
How about we publish your home phone number so that they can complain
to you directly? If you don't like the way German quotes work in
Debian, then call Michael Stone at XXX-XXX-. If you're right
that this is a trivial issue which nobody will care
On Tue, Aug 31, 2004 at 02:14:48PM -0700, Thomas Bushnell BSG wrote:
Actually that's not a real technical reason. If you could point to
a package with a bug that would be a serious problem if people used
UTF-8, then that would be a real technical reason. But saying it
isn't required for sarge
On Tue, Aug 31, 2004 at 02:29:21PM -0700, Thomas Bushnell BSG wrote:
But the problem here is that you seem totally unable to seek
compromise. I'll try again.
Good grief, this isn't personal. Maybe you should just relax and come
back tomorrow.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL
On Tue, Aug 31, 2004 at 02:36:25PM -0700, Thomas Bushnell BSG wrote:
I agree that an apology isn't necessary, but *some* kind of advice,
given that sarge will be *removing* support for a large class of users,
That's not true. Something is changing, arguably for the worse. Nobody
is being
On Tue, Aug 31, 2004 at 03:21:05PM -0700, Thomas Bushnell BSG wrote:
Perhaps you could write down some of the more frequent problems that
users with UTF-8 might expect to see
No. I have no interest in this problem and don't care to work with you.
I've reassigned the coreutils bug to libc6 and
On Thu, 29 Jul 2004 13:17:13 +0200 Thiemo Seufer
[EMAIL PROTECTED] wrote:
It shows how important guillemots are in everydays typing. And IMHO
everydays reading should use the same characters.
I think this argument is somewhat a red herring. I see a lot of people in
this thread calling an
On Sun, Aug 10, 2003 at 10:11:03PM +1000, Martin Michlmayr wrote:
Perhaps someone (Paul?) could write a summary of deprecated features
(e.g. tail -1) which we could post to devel-devel-announce. I think
many people are not aware of the whole situation at all.
For coreutils: (this stuff *will* use
On Tue, Apr 22, 2003 at 12:06:47AM +0900, GOTO Masanori wrote:
drawbacks. But from IST example, uniqueness of timezone name is not
the absolute requirement. I guess your question is derived from
timezone should be unique,
It would solve problems, and I have yet to hear a downside. The fact
that
reassign 95254 libc6
thanks
This bug goes to libc6 because the ambiguity is introduced by it, not
coreutils. date(1) includes a bison parser, but that only parses the
input--the output is generated by strftime. There's no parser in the
world that can guess what EST is supposed to mean if it has
Well it's not coreutils bug, and I think it's not glibc bug; see my
mail in #93810.
I don't agree with your conclusion. AEST and EST may both be used, and
EST may even be more prominant in .au. (Of course, the google search
results aren't useful because it's unclear which EST the hits refer
The same item as 175529?
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: libc6
Version: 2.1.2-1
Severity: Important
The attached code is part of an autoconf test. It hangs in the
mktime_test function on faure, but works fine on other platforms.
#line 3148 configure
/* Test program from Paul Eggert ([EMAIL PROTECTED])
and Tony Leneis ([EMAIL PROTECTED]).
33 matches
Mail list logo
