Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

[Michael Stone]

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 set of new
rules for a new universal "en" locale ;-) )


Exactly: using "C" implies compatability with the old POSIX rules, "en" 
implies you can do whatever you want. :)

C + POSIX locale question

[Michael Stone]

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?

Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

[Michael Stone]

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 sorting, whereas "en" would
> have
> case-insensitive sorting like en_GB.utf8 does? (If that's the only
> difference, then perhaps something like "LANG=C.utf8
> LC_COLLATE=en_US.utf8"
> is enough.)

POSIX specifies the output format for various utilities in the C locale,
which defeats my understanding of the purpose of this proposal. So, for
example, in ls -l:


I don't think the "C.UTF-8" locale covered by any promises POSIX might
make for "C".  (Nor is what happens when no LC_*, LANG vairables are
set at all.)


IMO, the principle of least surprise applies here: if C.UTF-8 is meant 
to be something other than the C locale with UTF-8 semantics added, it 
should be called something other than C, no?

Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

[Michael Stone]

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 something like "LANG=C.utf8 LC_COLLATE=en_US.utf8"
is enough.)


POSIX specifies the output format for various utilities in the C locale, 
which defeats my understanding of the purpose of this proposal. So, for 
example, in ls -l:


(quoting http://pubs.opengroup.org/onlinepubs/009695399/utilities/ls.html)
The  field shall contain the appropriate date and 
timestamp of when the file was last modified. In the POSIX locale, the 
field shall be the equivalent of the output of the following date 
command:


date "+%b %e %H:%M"

if the file has been modified in the last six months, or:

date "+%b %e %Y"

(where two s are used between %e and %Y ) if the file has not 
been modified in the last six months or if the modification date is in 
the future, except that, in both cases, the final  produced by 
date shall not be included and the output shall be as if the date 
command were executed at the time of the last modification date of the 
file rather than the current time. When the LC_TIME locale category is 
not set to the POSIX locale, a different format and order of 
presentation of this field may be used.


Mike Stone

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

[Michael Stone]

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 doesn't just generate a uuid itself. 
There's a large body of work ensuring reasonable uniqueness for uuids, 
and there isn't a clear benefit to clinging to getuid. Even on solaris 
there's a big honkin' warning on the man page that it isn't guaranteed 
to be unique (IIRC, getuid on containers reflects the hardware the 
container is running on). 


Mike Stone

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

[Michael Stone]

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 ID (no) or 
is it something that reflects the hardware (no)? Picking one will annoy 
the people who think it's the other, even though both are currently wrong.



I am not even sure it's a good idea to fix this, it might be better to
just mark this function as deprecated, and encourage existing users of
this function (including hostid) to use something much longer than
32-bit to avoid collisions.


That's my vote, except that hostid(1) probably shouldn't change except 
to say that nobody should use it.



One thing is sure however, if we change the current behaviour, it will
change the hostid on many systems, including ones which do not return
007f0101.


Yes, changing it will likely be bad in the off chance that someone is 
actually using the value. If you want to "fix" it (that is, define 
semantics) it would be better to create a new system call than to change 
the return value of a system call whose only semantic is that it returns 
a stable value in some (not fully defined) case. Or just explain to 
people how to use the options that already exist.


Mike Stone

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

[Michael Stone]

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 the kernel instead
of using gethostid(), which isn't really depricating the feature, only
the way to get access to it.  A quick search did not show any other
platforms depricating the function and feature, so I am curious to learn
what those are.


openbsd deprecates it, netbsd doesn't have it at all. neither of those 
platforms is likely to have a useful value unless you set it yourself. 
I'd wonder where this *is* expected to be useful value more than I'd 
wonder where it isn't.



My proposal is to use the DMI info which should stay the same
independent of OS installation.


Which doesn't exist on many, many platforms. If you need an ID tied to 
the hardware that's the one to use, but you have to know that the 
hardware you're deploying to actually supports that feature.



The users I am aware of is zfs-linux and the tools we wrote at work to
detect when a Linux machine was reinstalled or had its hardware changed.


For the latter case, just use the smbios values directly (assuming 
you're buying enterprise style hardware, it should support machine 
uuids.) That way you know that you're getting something tied to the 
hardware, instead of hoping.



The use case of zfs-linux require the ID to be unique among the machines
sharing a storage solution, and not globally unique.


I can't understand why, for that use case, zfs-linux wouldn't simply 
create a uuid itself. I see no obvious advantage in the program trying 
to fix the semantics of a fundamentally broken function that was 
introduced in BSD in the 80s and was removed from BSD itself back in the 
90s.



A search in the source of all Debian packages[1] show this list of 148
packages mentioning the string 'gethostid': actiona alpine amanda
apcupsd aplus-fsf arpwatch ats-lang-anairiats audit bacula bareos
bluefish bsdgames burp busybox casacore cde cdrdao cdrkit
chromium-browser cl-irc clisp cmucl condor coreutils ctwm cython dc3dd
dcmtk deheader deja-dup dicom3tools dietlibc dist dmtcp dx e17
eclipse-titan edk2 emscripten erlang facter fpc frama-c freebsd-utils
freetds fs-uae ga gcc-h8300-hms gdb ghc glibc gnucash gnulib
gnustep-netclasses golang golang-1.6 golang-1.7 golang-golang-x-sys
hercules highlight hugs98 hurd iputils isdnutils ivtools kfreebsd-10
krb5 ksh latrace ldc libcanberra libconvert-binary-c-perl
libdata-uuid-perl libexplain libpam-tacplus libpcap libposix-2008-perl
linux linux-grsec ltrace lua-posix manpages manpages-de manpages-es
manpages-fr manpages-ja manpages-pl metview minc-tools mingw-w64 mono
mono-reference-assemblies musl nam ncbi-tools6 netatalk newlib nim nmap
nordugrid-arc ns2 ntirpc nwchem open-iscsi open-vm-tools openafs openmpi
otp pidgin pidgin-nateon pimd polygraph praat prayer pulseaudio
python-ptrace qemu radare2 rat roaraudio samhain sbcl silo-llnl sipxtapi
slirp smlnj sniffit spl-linux splint strace talksoup.app tau tcpdump
tcpslice tkrat topal trinity tripwire uclibc uclmmbase uhd uw-imap vde2
xfsdump yap zephyr zfs-fuse zfsutils.

I do not know what they use gethostid() for. :)


Pulling a couple at random:
libpcap -- the only occurance is in lbl/os-sunos4.h 
which is basically a list of function prototypes from a long obsolete OS 
for historic curiosity.


xfsdump -- honestly seems like a bug or at least a misunderstanding: 
ghdrp->gh_ipaddr = ( uint64_t )( unsigned long )gethostid( )


cdrdao -- questionable assumption in scsi-sun.c:
cpu_type = gethostid() >> 24

burp -- contains a couple of prototypes for the function, checks for it 
in configure, doesn't seem to actually use it


This really is a function with no current value that should just be 
forgotten. And certainly don't make random assumptions about the value 
it returns.


Mike Stone

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

[Michael Stone]

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=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null
   fi
fi


That's not very different from /etc/machine-id, isn't it?


We need to figure out how to transform the UUID to a 32 bit integer,
of course.


And I think this is the crux of the problem.  Whatever we do, with
today's cluster sizes it's just not reliably unique.

You could use /etc/machine-id instead.  Some effort goes into that to
make it actually unique.

DMI data seems risky because it depends on firmware, and there are so
many firmware bugs out there.  It would also not address the matter of
changing host IDs as the result of host migrations.


Yes, this seems a quixotic quest. In historic terms, this was mostly 
used on systems that actually had some kind of serial number burned onto 
the mainboard; it's fairly useless in the absence of that kind of 
controlled environment. Many systems these days actually do have that 
sort of ID, e.g., via dmi/smbios, but 1) it's not guaranteed to be there 
2) it's unlikely to fit in a 32 bit int.


Other platforms have deprecated gethostid, that's the best way forward for 
linux, IMO. This proposal doesn't fix the problem generally and actually 
changes the semantics of the call. (It was originally expected that the 
value would remain constant independent of a particular OS installation, 
which is not a property of a value stored on disk.) The main users of 
hostid (that I'm aware of) tended to be commercial software vendors 
locking licenses to systems--and they typically didn't use gethostid on 
linux because it was useless for the purpose. So I'm not aware of a 
userbase for this call on linux, and nobody should be using it for new 
development. If you need a stable unique id then you should be using 
something like the dmi uuid *and you need to have hardware from a vendor 
that sets such a property*. 

If you want something tied to the OS instance rather than the machine, 
then use /etc/machine-id (and gnash your teeth at the misnomer) rather 
than reinventing it.


Mike Stone

Re: Processed: Re: Bug#769850: libc6: file not showing up

[Michael Stone]

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...@msgid.mathom.us

Bug#557596: gaih_inet logic for summarizing gethostbyname4_r results broken

[Michael Stone]

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 calls these procedures
and then attempts to combine the results from all available plugins.

Unfortunately, in the following scenario, the combination step is performed
incorrectly:

  1. Install your NSS plugin so that it is called after the
 libnss_dns-2.10.1.so plugin.

  2. Remove your default route. 


  3. Call getaddrinfo(NODE, SERVICE, NULL, &results).
  
The problem is that the third call, internally, results in a call to 


  _nss_dns_gethostbyname4_r()

which returns NSS_STATUS_UNAVAIL with herrno = TRY_AGAIN. This combination of
return and error codes causes gaih_inet()'s logic to set 


  no_data = -3.

This variable is used to signal to the rest of the gaih_inet procedure that no
results are available.

Unfortunately, when your plugin returns NSS_STATUS_SUCCESS and sets herrno =
NETDB_SUCCESS, your plugin's results will be *ignored* because gaih_inet
exits its loop without resetting no_data.

The attached patch fixes the problem for me. The patch was tested with code
from http://wiki.laptop.org/go/Dnshash.

-- System Information:
Debian Release: squeeze/sid
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable'), (500, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--- a/sysdeps/posix/getaddrinfo.c   2009-11-22 16:21:19.0 -0500
+++ b/sysdeps/posix/getaddrinfo.c   2009-11-22 16:28:26.0 -0500
@@ -715,7 +715,10 @@ gaih_inet (const char *name, const struc
   tmpbuflen, &rc, &herrno,
   NULL));
  if (status == NSS_STATUS_SUCCESS)
-   break;
+   {
+ no_data = 0;
+ break;
+   }
  if (status != NSS_STATUS_TRYAGAIN
  || rc != ERANGE || herrno != NETDB_INTERNAL)
{

Re: g#515731: touch: setting times of `/var/lib/update-notifier/dpkg-run-stamp': Function not implemented

[Michael Stone]

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 version.


strace output attached, but to cut a long story short:

utimensat(0, NULL, NULL, 0) = -1 ENOSYS (Function not   
implemented)


That was my guess. Does lenny work in this configuration?


The coreutils in my lenny guest works fine, yes.


Summary: linux 2.6.18-xen, lenny coreutils works but new unstable 
coreutils does not. My best guess is that it has to do with the libc6 
that coreutils was built against (6.10 was built against 2.6.1-2). I'll 
try building 6.12 against an older libc6 and make that available for 
testing. I'd also appreciate reports from anyone else who can duplicate 
this, to see if it's a xen-specific issue. I'm trying to put together a 
vm environment with a 2.6.18 kernel to see if I can duplicate it that 
way.


Mike Stone


--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

segfault within libc function?

[Michael Stone]

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(3) function, and there's nothing sort can do about this. Is that 
true? 


Mike Stone


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#355109: libc6.1: ia64 build failure for coreutils

[Michael Stone]

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: 
/build/buildd/coreutils-5.94/build-tree/coreutils-5.94/tests/misc/pwd.tmp/25528/z[...]

The above is part of the build tests. For some reason this assertion
occurs on ia64, but every other architecture builds fine, suggesting a
problem in the ia64 toolchain.

This build failure is going to keep coreutils out of testing, so I'd
really like to get some kind of response. My next step is to disable
build tests on ia64, but I'd really rather fix the bug rather than hide
it (and ignore other potential problems by skipping the tests).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#343140: resolver uses search list before other addresses

[Michael Stone]

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 resolver invocations 
gethostbyname(3) should cause, the glibc behaviour is correct and will 
result in the second list of DNS queries you specified.


ISTM that's an issue the user user shouldn't have to care about. 
gethostbyname(3) could be implemented as _four_ distinct resolver 
invocations:


if (inputname doesn't end in ".") {
 resolve(inputname., )
   return if found
 resolve(inputname., A)
   return if found
}
resolve(inputname, )
 return if found
resolve(inputname, A)
 return if found

Which would make the results match the requested behavior without a 
major rewrite. "The code does something that makes sense if you look at 
the code" isn't, in itself, a very good reason not to do something 
different.


Mike Stone


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#343140: resolver uses the search list before other address families

[Michael Stone]

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 subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#342313: getcwd assertion

[Michael Stone]

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 message:

pwd: ../sysdeps/unix/sysv/linux/getcwd.c:130: __getcwd: Assertion `__libc_errno 
!= 34 || buf != ((void *)0) || size != 0' failed.

The pwd test is checking behavior of a long directory path, which IMO
should result in an errno return, not an assert failure. See
http://buildd.debian.org/fetch.php?&pkg=coreutils&ver=5.93-5&arch=ia64&stamp=1132768587&file=log&as=raw

Mike Stone


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: coreutils failure on ia64

[Michael Stone]

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 a bug in libc -- pwd is causing an assertion there, and I
guess some ia64 specific code is called at some point, that either broke
between 2.3.5-3 and 2.3.5-7/2.3.5-8, or the new version of coreutils is
tickling the bug, where it didn't before.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#271428: Processed: your mail

[Michael Stone]

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

Bug#271428: Processed: your mail

[Michael 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 differently, it's been confusing users for years.
Did you read my mail?
Yes, and it's not the first time you send a mail with no interest in
people's legitimate concerns without offering a rationale for your own
position.
If people really want to use oddball timezones there is a simple
procedure for adding a new zoneinfo file.
Why don't you think people should check using tzselect and so on?
Because they don't. We've gotten varients of this bug on a regular basis
for years. The current situation is obviously suboptimal, and obviously
confuses our users. In general we try to write software such that if
someone makes a typo the software gives them some indication that
they've done something wrong so that they can fix it. But in this case
the software does something completely unexpected and silently gives out
unexpected data. And so far you haven't given any indication of why you
think that's a good thing and the proposed solution is a bad thing.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#271428: Processed: your mail

[Michael 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 when the
requested timezone cannot be found, or it should specify which
timezone is at the basis of the date and time it reports.
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 differently, it's been confusing users for years. If
people really want to use oddball timezones there is a simple procedure
for adding a new zoneinfo file.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#228486: Apology to german users required in the release notes

[Michael Stone]

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't see further traffic
on this issue. You've seen my warning about utf8 and can make of it what
you will, it matters not in the least to me.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#235759: Bug#228486: Apology to german users required in the release notes

[Michael Stone]

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 unsupported. Inflating the hyperbole isn't productive.
does seem relevant, and does warrant some kind of mention in the
release notes to explain the situation.
I don't recall saying that a mention in the release notes is
inappropriate or unacceptable. I don't recall objecting to the proposed
wording. The only thing I recall objecting to was the specific term
"apology". 

The UTF-8 issue is something I said I'd "hesitate" to recommend. That
was simply a way to raise a potential issue for consideration, as I had
not seen it discussed previously in the thread--I didn't expect it to be
taken as some sort of veto. Hesitating in order to consider doesn't
mean that the proposal is wrong or invalid, nor is it any way
pejorative. It's simply taking some time to make sure that the proposal
won't bite anyone down the road. 

Mike Stone

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#235759: Bug#228486: Apology to german users required in the release notes

[Michael Stone]

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]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#235759: Bug#228486: Apology to german users required in the release notes

[Michael Stone]

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" doesn't mean that it actually doesn't
*work*.
I didn't say it did. I pointed to a potential problem. For all I know,
in an exclusively german context UTF-8 won't cause problems at all. What
I did say is that full multibyte compliance isn't guaranteed. That's a
fact. Now, those suggesting that a bunch of people who aren't currently
using UTF-8 suddenly start using it should look at the current state of
affairs and decide whether that's a good idea. IOW, is the quote issue a
big enough problem that we should suggest that all german users by
default use a less tested environment? I would suggest that those
proposing the change bear some responsibility for testing that
configuration from scratch to see what kind of impact it might have on a
new user's experience, compared to the current mode of operation. If
someone were to do that in a comprehensive fashion then I'd have no
question at all about the proposed change--but I doubt there's really
time for that given the number of packages in sarge. 

FWIW, I use a UTF-8 locale on sarge and sid exclusively, and I have
seen no multibyte-related problems.
I also use a UTF-8 locale, and I can assure you that there are. Most are
surmountable, but will raise the complexity of an installation. (It's
not just "use LANG=de_DE.UTF-8 and everything will magically work" in an
upgrade scenario. Maybe not even in a new install--I don't know. Think
things like terminal emulator settings, fonts, remote sessions, etc.)
There are definately, e.g., issues with multibyte support in coreutils.
How much impact the issues have in the current context, I don't know.
Several weeks into the freeze might not be the right time to start
quantifying this.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#235759: Bug#228486: Apology to german users required in the release notes

[Michael Stone]

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. Do you have
any response to my *technical* concern? If there are issues with
multibyte support in sarge it would be necessary to weigh the chance of
breaking things (remember, setting the locale to UTF-8 affects a *lot*
more than quotation marks) against the aesthetics of quote
transliteration. If the german translation team decides that the quotes
are more important than the potential breakage, so be it. Personally I
think that's an incredible overreaction, but I'm not using a german
locale and have no particular stake in what recommendation is made. 

Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#235759: Bug#228486: Apology to german users required in the release notes

[Michael Stone]

On Tue, Aug 31, 2004 at 01:33:00PM -0700, Thomas Bushnell BSG wrote:
Are you just trying to make it as difficult as possible to solve the
problem?  
No, I'm aghast that the concept of including an *apology* in the release
notes for a typographical ugliness is being given any consideration at
all. Talking about solutions is fine, but singling something like this
out for an apology is ludicrous.
English quotation marks have never looked good.  But the German ones,
with the most natural German locale, are now looking *worse than they
used to*.  It's one thing to say "it's not as good as it could be",
but when you insist that it's ok to *make things worse* on the grounds
that English is already sucky, you aren't going to win points.
Personally, *I don't care* what quotes are used in german, since I'm
unlikely to ever use a german locale. The purpose of bringing up the
english example is to demonstrate that people *can* and *do* live with
stupid looking quotes. I'd far prefer a solution where everyone is
happy, but running around like headless chickens proclaiming the end of
the world and demanding apologies because quotation marks look stupid
is, well, silly.
Nor is this about winning points.  
No, it's not. It's about being a little more reasonable when demanding
changes. Sometimes you get what you want and sometimes you don't.
Marshal your arguments and do something productive. At this point it
looks like focusing attention upstream is going to be more productive
than continuing with gotom. Alternatively, someone could try the TC
route. Either way it's too late for sarge, but that *really isn't* the
end of the world.
I get the feeling that you wish those annoying furriners would go away
with their funny marks and quaint obscure languages.  But Debian has
already decided we are going to support non-English languages as well
as we can, and it is inappropriate for you to attempt to subvert that
for whatever reason.
It is inappropriate (and, frankly, offensive) for you to make insuations
about my motives. 

Some background: the logic behind using ,," isn't that ,," is commonly
used as a quote in german any more than `' or ``'' is commonly used as a
quote in english.  The logic is that the computer screen (and printed
output) should try to *look* like the original quote even if the current
locale doesn't have an appropriate glyph to represent the quotation
mark. Personally I think that's a damn stupid idea, but arguments about
,," not being a standard quotation mark completely miss the point of
what is being done and why. I'd like to see a rational debate about the
overall goals of transliterating quotes, but the chances of that seem
remote in the current context. The bottom line isn't that this isn't
some conspiracy to foist some non-standard quote off on germans, this is
simply a difference in goals and expectations.
The German l10n team gets to decide how German localization happens,
not you, and not me.
So you should butt out too, right? Take your high horse with you.
It's sadly too late to get a fix into sarge (and it's a shame that the
Debian glibc maintainers acted like jerks about it).  
I'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?  "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 about, you should
be happy with that solution, right?
Don't be an ass. I replied with a real technical reason why you might
not want hordes of people switching to UTF-8 and you suggest *that* as a
reasonable response? I had thought better of you.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#235759: Bug#228486: Apology to german users required in the release notes

[Michael Stone]

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, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#235759: Bug#228486: Apology to german users required in the release notes

[Michael Stone]

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 grave
accents. There is a proper double opening quote for english in UTF-8,
just like there's a proper double opening quote for german in UTF-8. The
only difference is that (until my previous post) english-speaking users
haven't demanded an apology for misusing punctuation.
Mike Stone

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#235759: Bug#228486: Apology to german users required in the release notes

[Michael Stone]

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.
The english quotes at least stick to the idea that one character is one
symbol.  
Ooh, you've never seen english double quotes represented like this: ``foo''
Now can I file a bug and cross post a message demanding an immediate fix
and an apology for all english speakers? 

This is ridiculous.
Mike Stone

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#235759: Bug#228486: Apology to german users required in the release notes

[Michael Stone]

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. English-speaking users have been
living with the problem for years.
Hence the appology is needed, since -- given Debians history -- users of
stable employing a german locale will experience the (unambiguously
perceived as ugly) quotes for the years to come.
Just like people employing an english locale! 

Mike Stone

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#235759: Bug#228486: More info about #228486 / #235759

[Michael Stone]

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 english quote; this is incorrect--a proper set of 
quotes in english is curved one way at the start of the quote and another 
way at the end. In fact, many word processing programs will insert the 
proper opening or closing quote when you type the " or ' key on the 
keyboard. I imagine that german word processors can (and do) operate the 
same way.

What's the point of all this? First, the symbol on the keyboard does not 
necessarily correspond with the character the user wants to use. Second, 
the absence of a character on a keyboard does not indicate that it is 
unimportant. Third, ASCII discriminates against proper english typographic 
quotes as much as german.  Finally, english translations also contain an 
ugly and stupid looking conversion of quotes using punctuation characters 
that have their own seperate meaning. It would be nice if everything used 
proper quotes, but stupid-looking quotes aren't the end of the 
world--english speaking users have been living with it for years.

Mike Stone


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: libc6 posix version/breakage

[Michael Stone]

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 the new behavior the minute
someone recompiles coreutils against libc6 2.3.2-2)
- chown: `.' is no longer recognized as a separator in the OWNER:GROUP
 specifier on POSIX 1003.1-2001 systems.  If chown *was not* compiled
 on such a system, then it still accepts `.', by default.  If chown
 was compiled on a POSIX 1003.1-2001 system, then you may enable the
 old behavior by setting _POSIX2_VERSION=199209 in your environment.
* The obsolete usage `touch [-acm] MMDDhhmm[YY] FILE...' is no longer
 supported on systems conforming to POSIX 1003.1-2001.  Use touch -t
 instead.
* The following changes apply on systems conforming to POSIX 1003.1-2001,
 and are required by the new POSIX standard:
  - `date -I' is no longer supported.  Instead, use `date --iso-8601'.
  - `nice -NUM' is no longer supported.  Instead, use `nice -n NUM'.
* The following obsolete usages are no longer supported when conforming
 to POSIX 1003.1-2001, which prohibits most digit-string options:
   expand -N   (instead, use expand -t N)
   head -N (instead, use head -c N or head -n N)
   fold -N (instead, use fold -w N)
   split -N(instead, use split -l N)
   tail -N (instead, use tail -c N or tail -n N)
   unexpand -N (instead, use unexpand --first-only -t N)
   uniq -N (instead, use uniq -f N)
 The following obsolete usages (options without arguments) are no
 longer supported when conforming to POSIX 1003.1-2001, which
 prohibits most options with optional arguments:
   od -s   (instead, use od --strings)
   od -w   (instead, use od --width)
   pr -S   (instead, use pr --sep-string)
* The following obsolete usages are no longer supported when conforming
 to POSIX 1003.1-2001, which prohibits most options with leading "+":
   sort +POS1 -POS2(instead, use sort -k)
   tail +N (instead, use tail -c +N or tail -n +N)
   uniq +N (instead, use uniq -s N)
I don't know that there's a full list of *packages* that might be
affected.
Mike Stone

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

libc6 posix version/breakage

[Michael Stone]

What led to this email is the fact that coreutils built under the
current libc6 exhibits behavior that breaks a *lot* of stuff in debian.
For example: head -number and tail -number don't work anymore, so
dpkg-buildpackage fails. Apparantly other gnu tools will exhibit the
same sort of changes as soon as someone rebuilds them against the
current unstable libc. One possibility is to change the reported posix
version in /usr/include/unistd.h. The downside to that is that it masks
the problem from a user perspective, but at least it would give us some
time to fix breakage in the debian packages. 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: [Coreutils-announce] coreutils-5.0.90 released
From: Paul Eggert <[EMAIL PROTECTED]>
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Several weeks ago an anesthesiologist walked up to me at a dinner
party and complained that his GNU/Linux box was giving him weird
diagnostics on his scripts.  It turned out Gentoo libc switched to the
new POSIX version, which caused coreutils to default to the new
behavior.  (Don't you just love 10-year-old POSIX time bombs?  They
make for fun dinner-party conversation.  :-)
> What I will probably have to do is change anything that's disabled in
> that case to succeed and print a "deprecated" message unless
> POSIXLY_CORRECT is defined. Any thoughts?
It's not just coreutils; other packages look at _POSIX2_VERSION.
(diffutils springs to mind, but I'll bet there are others.)
How about this much-simpler workaround instead: patch glibc so that
_POSIX2_VERSION has its old value.  That is more honest, since you
probably still have some programs that don't conform to POSIX
1003.1-2001 yet.  _POSIX2_VERSION is supposed to say what standard
your utilities conform to; glibc doesn't really know what the proper
value for that is, so you can fix its guess with a light heart.
This simpler workaround will give you some time to fix the rest of
Debian.  Debian developers like yourself should set
_POSIX2_VERSION=200112 in their environments, and let the bugs get
found and squashed.
You can remove the glibc patch in a few months (or years), after the
dust has settled somewhat.

Someone needs to file bugs against the offending packages.
Here's a tiny start.  I'm sure there's a lot more
I've been filing bugs as I encounter them.  E.g., Debian bugs 191669,
203292, 204361, 204372.
Here's the script that I use to find potential problems.  I call this
command 'grep-nonposix'.  I can send you the output of it on a Debian
testing host, if you like.  (I don't use Debian unstable; Jim's braver
than I am.)  Or I can file bug reports from the output, if you'd
prefer that.
#! /bin/sh

LC_ALL=C
export LC_ALL
IFS='
'
pattern='(expand|head|fold|split|tail|uniq|unexpand|nice|diff)\>.*[	 ]-[a-zA-Z]*[0-9]|(sort|tail|uniq)\>.*[	 ]\+[0-9]+[a-zA-Z_]*|sort\>.*[	 ]-o'

case $1 in
--help)
 exec echo "$0: usage: $0 [OPTION]... [FILE]...
Grep for instances of possible POSIX-conformance problems in the FILEs.
Options:
 -s  Check strictly, even for things that aren't likely to be real problems.
The FILEs can be directories, in which case the greps are recursive,
though ChangeLogs, backup files, and version-control histories are bypassed.
The default FILE is '-', which stands for the standard input.";;
-s)
 pattern=$pattern'|[ef]grep\>|(\[|test\>).*[   ]-[ao]\>'
 shift;;
esac
pattern='\<('$pattern')'

case $# in
0) exec grep -E -n "$pattern";;
*) exec grep -E -n "$pattern" \
$(find "[EMAIL PROTECTED]" -type f \
! -name '*~' ! -name 'ChangeLog*' ! -name '*,v' \
-print \
  | sort);;
esac
- End forwarded message -

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#93810: Processed: reassign 95254 coreutils

[Michael Stone]

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 some timezones might not be unique doesn't seem a good argument
against fixing those that can be.
Mike Stone

Bug#93810: Processed: reassign 95254 coreutils

[Michael Stone]

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...) But it seems that people in .au can understand what AEST refers
to and that using AEST would eliminate some confusion. I don't see a
down side to using AEST instead of EST.
Mike Stone

Re: Processed: reassign 95254 coreutils

[Michael Stone]

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 two
completely different meanings. 

env TZ=Australia/NSW perl -e 'use POSIX qw(strftime); $_=strftime("%Z",localtime); printf "$_\n";'
EST
Note that this is only stftime, not date(1) and that the TZ output is
"EST". If you don't want to fix this you can close it, but you can't
reassign it to me.
Mike Stone

Re: Bug#164766: Problem with VIA C3 chip and libcrypto

[Michael Stone]

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 Pentium MMX (i586 MMX) are 'i586 class
processors'.


This bit is a good idea but...

[snip]

Let's not do anything about this until someone gets clarification from
GCC that -march=i686 is not actually supposed to be a 686, OK?


Why? Even if gcc didn't use cmov with -march=i686, is there another
facility for using cmov in an optimized library? IOW, this ld.so
extension sounds like something useful regardless of the state of gcc.

Mike Stone


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#175163: [lee@sectionIV.com: Re: mutt/libc? problems after recent sid upgrade]

[Michael Stone]

The same item as 175529?

Mike Stone


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#47584: libc6.1: localtime() hangs on alpha

[Michael Stone]

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]).  */
#if TIME_WITH_SYS_TIME
# include 
# include 
#else
# if HAVE_SYS_TIME_H
#  include 
# else
#  include 
# endif
#endif

#if HAVE_UNISTD_H
# include 
#endif

#if !HAVE_ALARM
# define alarm(X) /* empty */
#endif

/* Work around redefinition to rpl_putenv by other config tests.  */
#undef putenv

static time_t time_t_max;

/* Values we'll use to set the TZ environment variable.  */
static const char *const tz_strings[] = {
  (const char *) 0, "TZ=GMT0", "TZ=JST-9",
  "TZ=EST+3EDT+2,M10.1.0/00:00:00,M2.3.0/00:00:00"
};
#define N_STRINGS (sizeof (tz_strings) / sizeof (tz_strings[0]))

/* Fail if mktime fails to convert a date in the spring-forward gap.
   Based on a problem report from Andreas Jaeger.  */
static void
spring_forward_gap ()
{
  /* glibc (up to about 1998-10-07) failed this test) */
  struct tm tm;

  /* Use the portable POSIX.1 specification "TZ=PST8PDT,M4.1.0,M10.5.0"
 instead of "TZ=America/Vancouver" in order to detect the bug even
 on systems that don't support the Olson extension, or don't have the
 full zoneinfo tables installed.  */
  putenv ("TZ=PST8PDT,M4.1.0,M10.5.0"); 
  tm.tm_year = 98;
  tm.tm_mon = 3;
  tm.tm_mday = 5;
  tm.tm_hour = 2;
  tm.tm_min = 0;
  tm.tm_sec = 0;
  tm.tm_isdst = -1;
  if (mktime (&tm) == (time_t)-1)
exit (1);
}

static void
mktime_test (now)
 time_t now;
{
  struct tm *lt;
  if ((lt = localtime (&now)) && mktime (lt) != now)
exit (1);
  now = time_t_max - now;
  if ((lt = localtime (&now)) && mktime (lt) != now)
exit (1);
}

static void
irix_6_4_bug ()
{
  /* Based on code from Ariel Faigon.  */
  struct tm tm;
  tm.tm_year = 96;
  tm.tm_mon = 3;
  tm.tm_mday = 0;
  tm.tm_hour = 0;
  tm.tm_min = 0;
  tm.tm_sec = 0;
  tm.tm_isdst = -1;
  mktime (&tm);
  if (tm.tm_mon != 2 || tm.tm_mday != 31)
exit (1);
}

static void
bigtime_test (j)
 int j;
{
  struct tm tm;
  time_t now;
  tm.tm_year = tm.tm_mon = tm.tm_mday = tm.tm_hour = tm.tm_min = tm.tm_sec = j;
  /* This test makes some buggy mktime implementations loop.
 Give up after 10 seconds.  */
  alarm (10);
  now = mktime (&tm);
  alarm (0);
  if (now != (time_t) -1)
{
  struct tm *lt = localtime (&now);
  if (! (lt
 && lt->tm_year == tm.tm_year
 && lt->tm_mon == tm.tm_mon
 && lt->tm_mday == tm.tm_mday
 && lt->tm_hour == tm.tm_hour
 && lt->tm_min == tm.tm_min
 && lt->tm_sec == tm.tm_sec
 && lt->tm_yday == tm.tm_yday
 && lt->tm_wday == tm.tm_wday
 && ((lt->tm_isdst < 0 ? -1 : 0 < lt->tm_isdst)
  == (tm.tm_isdst < 0 ? -1 : 0 < tm.tm_isdst
exit (1);
}
}

int
main ()
{
  time_t t, delta;
  int i, j;

  spring_forward_gap ();
  for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2)
continue;
  time_t_max--;
  delta = time_t_max / 997; /* a suitable prime number */
  for (i = 0; i < N_STRINGS; i++)
{
  if (tz_strings[i])
putenv (tz_strings[i]);

  for (t = 0; t <= time_t_max - delta; t += delta)
mktime_test (t);
  mktime_test ((time_t) 60 * 60);
  mktime_test ((time_t) 60 * 60 * 24);

  for (j = 1; 0 < j; j *= 2)
bigtime_test (j);
  bigtime_test (j - 1);
}
  irix_6_4_bug ();
  exit (0);
}