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 s
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 so
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 Thu, Sep 29, 2016 at 12:30:39AM +0200, Aurelien Jarno wrote:
Another question is about chroots. The above methods means we might
end-up with the same machine-id in chroots id the DMI UUID is available.
Is it something really wanted?
One of the many ambiguities of gethostid. :) Is it a unique
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
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 if=/
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:
https://lists.debian.org/b7a76a54-ca36-11e4-8add-00163eeb5...@m
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__gethostbyname4_r() and
_nss__gethostbyname2_r().
The function gaih_inet() in libc dynamically loads and call
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
strcoll(
Package: libc6.1
Severity: important
http://buildd.debian.org/fetch.php?&pkg=coreutils&ver=5.94-1&arch=ia64&stamp=1141336896&file=log&as=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
Ok, let's clarify some things here. resolv.conf(5) describes the
behaviour of a _single_ resolver query. If you look at
resolv/nss_dns/dns-host.c in the glibc source, you'll see that
gethostbyname(3) is implemented as _two_ distinct resolver invocations.
Since it is nowhere specified how many
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 subjec
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 messag
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=coreutils&ver=5.93-5&arch=ia64&stamp=1132768587&file=log&as=raw
Looks to me like
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 09:19:42PM +0900, GOTO Masanori wrote:
At Sat, 25 Sep 2004 07:23:27 -0400,
Michael Stone wrote:
No, not date. date has nothing to do with this, it's a libc function
(which is why it's reassigned to libc). I fully agree that *libc* should
handle the case differe
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 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 won'
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 unsupporte
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 PROTECTED
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:09:36PM -0700, Thomas Bushnell BSG wrote:
Are you willing to compromise?
What is there for me to compromise about? I pointed out a potential
*technical* problem with your proposal and you jumped all over me and
suggested that my phone number be put in the release notes. D
;ve had my own problems in that area, but *I didn't demand a damned
apology in the release notes*.
I hesitate to tell people to use UTF-8 because full multibyte compliance
isn't guaranteed in sarge.
How about we publish your home phone number so that they can complain
to you directly? &q
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,
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 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 g
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. Englis
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
kages. The right answer is to
probably plan a transition on debian-devel. Thoughts?
- Forwarded message from Paul Eggert <[EMAIL PROTECTED]> -
X-Original-To: [EMAIL PROTECTED]
To: Jim Meyering <[EMAIL PROTECTED]>
Cc: Michael Stone <[EMAIL PROTECTED]>
Subject: Re: [Coreut
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
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
to...
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 t
On Fri, Jan 17, 2003 at 10:29:03AM -0500, Daniel Jacobowitz wrote:
This libc ld.so special handling for hardware capability is used by
only MMX currently. We expand it not only for MMX but also CMOV.
MMX, intel's multi media extension, is also same circumstance that
both Pentium (i586) and Pentiu
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]).
39 matches
Mail list logo