[Pkg-sysvinit-devel] Bug#343645: Waste of...

[Henrique de Moraes Holschuh]

> Henrique de Moraes Holschuh asked:
> > Simplistic as in?  What did it fail to do?
> 
> Thomas E. Dickey replied:
> > It wasted my time.
> 
> Thomas Hood wrote:
> > Who is wasting whose time?  You make derogatory comments and then don't bother
> > to explain what you mean.

Well, I can only guess that Mr. Dickey wanted to tell us that the solution
wasn't perfect or somesuch.

Anyway, I got no useful feedback to know for sure, and frankly, since I had
never involved Mr. Dikey directly on anything to begin with, I decided it
would be better for all involved if were not to "waste his time" any further
asking for more details.

And yes, as it is public knowledge, the way Mr. Dikey's reply was worded
pissed me off at the time, and soured my will to keep working on this issue
for enough time that other high priority Debian work showed up (but at
least, that one is now mostly done with, and I should finish it in two or
three days).

Now, to keep the waste of time to a minimum and avoid further angry (or
aggravating) emails from anyone to anyone over this whole deal: all I know
about the RTC problem and the best solution [the up-to-date one] I came up
with for solving it is at
http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2006-January/000635.html
and future posts in that thread.  If someone else wants to address the
issue, I am not holding back anyone or anything.  If nobody wants to, I will
get to it eventually, the fact that the early boot is broken re. timezones
does bother me.  If anyone has better ideas, please kindly describe them in
a post to the above thread.

Here's the status of various packages related to the issues re. hwclock and
the RTC in local time, at the best of my knowledge.  Please correct any
oversights:

* AFAIK, Initscripts have nothing to fix: nothing in our scripts care if you
  do whatever to the clock while they aren't running.  We don't depend on
  correct timekeeping much -- if at all -- as long as sleep() still works.
  We just need to remain aware of that and never let stuff that potentially
  changes the clock run in parallel with anything else.

  Trying to work around the RTC in localtime with initscripts hacks is not
  something that I will bother to pursue anymore, IMHO it is not worth the
  effort and risk of breakage (but it works in controlled environments, I
  tested).

* util-linux has scripts to fix, they are not doing what they are supposed
  to do right now -- but it can't fix by itself the RTC in localtime issues
  at early boot, and what the hwclock initscripts need to do changes after
  the glibc fix (because /usr and timezones won't be reasons for the second
  invocation of hwclock.sh anymore, just /etc/adjtime).

  Status of the patches sent there is unknown, but I am uninclined to bother
  Lamont until after the glibc stuff gets done.  The patches will benefit
  from extra work to remove uneeded functionality from the second call of
  hwclock.sh *after* glibc starts supporting /etc/localtime as a real file.
  
* e2fsck doesn't seem to do anything else than reset timestamps in the
  future, now.  At least this is what I gather from the bug report.  That
  would mean the boot won't stop if it is in autorepair mode, unless e2fsck
  requests a reboot after fixing a timestamp problem.

* glibc can greatly improve the support of timezones during early boot, and
  they're open for a bug report describing what needs to be done, priority
  "important", with full patches, and a description on how the solution was
  tested and for how long.  They were quite helpful when I approached them
  about it, and I agree with their request that it should be well tested
  before deployed, and that it should go through experimental first.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh