Re: [lfs-dev] New failure in coreutils tests

2012-05-13 Thread Olaf
On 2012-04-29 07:09, Matt Burgess wrote:
 On Sun, 2012-04-29 at 00:39 +0100, Ken Moffat wrote:

   I'm assuming this is from gnulib-tests/test-getlogin.c.  Not seen
 this failure in my builds earlier this week, perhaps it's a one-off
 or perhaps something in the 3.3.4 headers has changed.

 There's a sed in the book to avoid the test failure.  The sed is not the
 right fix, but I'm working on-and-off with upstream to try and get to
 the bottom of the issue.

I see a test failure too, but only if I run the testsuite via an 
automated script *and* in a cronjob (talk about adding multiple 
complications ;-)).

test-getlogin.log shows the line throwing the error:
test-getlogin.c:48: assertion failed

The 'offending' line in test-getlogin.c is:
   ASSERT (isatty (0));


Since my test environment is somewhat out of the ordinary, I'll live 
with a sed/patch and not try to figure it out.


Olaf
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: [lfs-dev] problem of bootscript setclock

2012-05-13 Thread Bryan Kadzban
xinglp wrote:
 Now, It is the job of udev to start /etc/init.d/setclock .
 
 When I use initd-tools to install somethings else, it was installed 
 for depended.

Is there a way in these newfangled headers to say that setclock is
really an alias for udev?  That's what's happening in the scripts, anyway...

 And I THINK , ntpd and checkfs should not depend on $time.

Not sure on ntpd (although I wouldn't be surprised if it was because
ntpd refuses to do anything if the clock is far-enough off from what
it's getting from the upstream servers).

But checkfs does depend on the time.  It checks whether the current time
is before or after the last-full-fsck-time plus the days-between-mounts
value stored in the ext3 (and probably 4, and perhaps 2) superblock.  If
it's after, then it forces a full fsck run.

(It also checks whether the mount count stored in the superblock is more
or less than the number-of-mounts-between-full-fsck-runs value in the
superblock, and forces a full fsck if it's more.  Of course, that
doesn't depend on knowing the current time.)

tune2fs -t will change the number of days between checks, and tune2fs
-c will change the number of mounts.  tune2fs -T timestamp will set
the last-checked time (can be done live), and tune2fs -C integer
will set the current mount count (can also be done live).

All that said, if there's no way in this extra-abstraction setup to
express an alias, then we should change the other scripts to depend on
udev instead of setclock.



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: [lfs-dev] problem of bootscript setclock

2012-05-13 Thread Bruce Dubbs
DJ Lucas wrote:
 On 05/13/2012 11:33 AM, Bryan Kadzban wrote:
 xinglp wrote:
 Now, It is the job of udev to start /etc/init.d/setclock .

 When I use initd-tools to install somethings else, it was installed
 for depended.
 Is there a way in these newfangled headers to say that setclock is
 really an alias for udev?  That's what's happening in the scripts, anyway...

 And I THINK , ntpd and checkfs should not depend on $time.
 Not sure on ntpd (although I wouldn't be surprised if it was because
 ntpd refuses to do anything if the clock is far-enough off from what
 it's getting from the upstream servers).

 But checkfs does depend on the time.  It checks whether the current time
 is before or after the last-full-fsck-time plus the days-between-mounts
 value stored in the ext3 (and probably 4, and perhaps 2) superblock.  If
 it's after, then it forces a full fsck run.

 (It also checks whether the mount count stored in the superblock is more
 or less than the number-of-mounts-between-full-fsck-runs value in the
 superblock, and forces a full fsck if it's more.  Of course, that
 doesn't depend on knowing the current time.)

 tune2fs -t will change the number of days between checks, and tune2fs
 -c will change the number of mounts.  tune2fs -Ttimestamp will set
 the last-checked time (can be done live), and tune2fs -Cinteger
 will set the current mount count (can also be done live).

 All that said, if there's no way in this extra-abstraction setup to
 express an alias, then we should change the other scripts to depend on
 udev instead of setclock.

 After a quick review of the scripts, here is my take: a quick fix would 
 be to add $time to the provides of the udev script headers. That's 
 probably not exactly the right thing to do. The setclock script should 
 probably be renamed hwclock and provide hwclock (at shutdown). Scripts 
 that need a close time source (hwclock) should depend on udev for 
 startup. The RTC will always be available to the hwclock program on x86 
 or x86_64 even if /dev is not mounted (the same is not true of other 
 archs though). I believe there is a way to set the system time by way of 
 kernel config now too so that the udev rule could go...been a while 
 since I looked at it. $time should probably be provided by the ntpd 
 script, and then a $time dependency should never appear in any script 
 that is installed into the rcS.d/, rc1.d/, or rc2.d/ directories.

For LFS, we can't rely on ntpd because we can't assume a network connection.

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: [lfs-dev] problem of bootscript setclock

2012-05-13 Thread xinglp
2012/5/14 Bryan Kadzban br...@kadzban.is-a-geek.net:
 xinglp wrote:
 Now, It is the job of udev to start /etc/init.d/setclock .

 When I use initd-tools to install somethings else, it was installed
 for depended.

 Is there a way in these newfangled headers to say that setclock is
 really an alias for udev?  That's what's happening in the scripts, anyway...
When I do `install_initd httpd`, it depends on $local_fs, then mountfs
, then checkfs then $time.
So the $time's provider setclock was installed in rcS.d.
Now, I just remove the Required-Start $time from checkfs,ntpd, and
add udev to them.
Letting udev provide the $time is better way than I what I did.

 And I THINK , ntpd and checkfs should not depend on $time.

 Not sure on ntpd (although I wouldn't be surprised if it was because
 ntpd refuses to do anything if the clock is far-enough off from what
 it's getting from the upstream servers).

 But checkfs does depend on the time.  It checks whether the current time
 is before or after the last-full-fsck-time plus the days-between-mounts
 value stored in the ext3 (and probably 4, and perhaps 2) superblock.  If
 it's after, then it forces a full fsck run.

 (It also checks whether the mount count stored in the superblock is more
 or less than the number-of-mounts-between-full-fsck-runs value in the
 superblock, and forces a full fsck if it's more.  Of course, that
 doesn't depend on knowing the current time.)

 tune2fs -t will change the number of days between checks, and tune2fs
 -c will change the number of mounts.  tune2fs -T timestamp will set
 the last-checked time (can be done live), and tune2fs -C integer
 will set the current mount count (can also be done live).

 All that said, if there's no way in this extra-abstraction setup to
 express an alias, then we should change the other scripts to depend on
 udev instead of setclock.


 --
 http://linuxfromscratch.org/mailman/listinfo/lfs-dev
 FAQ: http://www.linuxfromscratch.org/faq/
 Unsubscribe: See the above information page

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: [lfs-dev] problem of bootscript setclock

2012-05-13 Thread DJ Lucas
On 05/13/2012 01:16 PM, Bruce Dubbs wrote:
 DJ Lucas wrote:
 On 05/13/2012 11:33 AM, Bryan Kadzban wrote:
 xinglp wrote:
 Now, It is the job of udev to start /etc/init.d/setclock .

 When I use initd-tools to install somethings else, it was installed
 for depended.
 Is there a way in these newfangled headers to say that setclock is
 really an alias for udev?  That's what's happening in the scripts, anyway...

 And I THINK , ntpd and checkfs should not depend on $time.
 Not sure on ntpd (although I wouldn't be surprised if it was because
 ntpd refuses to do anything if the clock is far-enough off from what
 it's getting from the upstream servers).

 But checkfs does depend on the time.  It checks whether the current time
 is before or after the last-full-fsck-time plus the days-between-mounts
 value stored in the ext3 (and probably 4, and perhaps 2) superblock.  If
 it's after, then it forces a full fsck run.

 (It also checks whether the mount count stored in the superblock is more
 or less than the number-of-mounts-between-full-fsck-runs value in the
 superblock, and forces a full fsck if it's more.  Of course, that
 doesn't depend on knowing the current time.)

 tune2fs -t will change the number of days between checks, and tune2fs
 -c will change the number of mounts.  tune2fs -Ttimestamp will set
 the last-checked time (can be done live), and tune2fs -Cinteger
 will set the current mount count (can also be done live).

 All that said, if there's no way in this extra-abstraction setup to
 express an alias, then we should change the other scripts to depend on
 udev instead of setclock.
 After a quick review of the scripts, here is my take: a quick fix would
 be to add $time to the provides of the udev script headers. That's
 probably not exactly the right thing to do. The setclock script should
 probably be renamed hwclock and provide hwclock (at shutdown). Scripts
 that need a close time source (hwclock) should depend on udev for
 startup. The RTC will always be available to the hwclock program on x86
 or x86_64 even if /dev is not mounted (the same is not true of other
 archs though). I believe there is a way to set the system time by way of
 kernel config now too so that the udev rule could go...been a while
 since I looked at it. $time should probably be provided by the ntpd
 script, and then a $time dependency should never appear in any script
 that is installed into the rcS.d/, rc1.d/, or rc2.d/ directories.
 For LFS, we can't rely on ntpd because we can't assume a network connection.

 -- Bruce
Correct, no scripts in the base LFS should have a hard dependency on 
$time for startup. You could still use should-* if desired, but no 
examples immediately come to mind where that would be appropriate (and 
that's not even necessary if the kernel is configured to set the system 
time). Scripts that need to have semi-accurate time (obtained from the 
RTC) should depend only on udev for start-up. A provides of hwclock for 
shutdown would be made available, though the only use of hwclock I can 
see is as a Required-Stop for the ntpd script. Few things should have a 
hard dep for $time, in fact, MIT Krb5 is the only one I can think of 
ATM  for BLFS (and Heimdal if it goes back in).

BTW, OT but just curiosity, why was MIT chosen to be kept over Heimdal? 
I would have thought Heimdal to clearly be the more capable of the two, 
though the extra functionality provided by Heimdal should be handled by 
PAM anyway, so no *real* loss. Heimdal will be the default krb5 provider 
for Samba 4 in the future (and included in the distribution, though you 
can still use a system instance of either if desired).

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page