Bug#387894: sysv-rc: progress bar

2006-09-17 Thread Jean-Damien Durand

Package: sysv-rc
Version: 2.86.ds1-20
Severity: normal

abour progress bar, here are few fixes and suggestions.

- in debug mode, probably the call to usplash_write should just be echoed
- the count of number of scripts executed is approximate v.s. what happens
 in reality (check if file exist, check of previous runlevel, etc.)
- the computation of what fraction of the bar to fill is not guaranteed to
 reach 0 or 100, because of rouding issues (100/3, then multiplied again)

Please find attached a patch for all these issues, where I factorized the call 
to kill
and start script in order to avoid code duplication. I let you check and/or 
reject it, no pb!
Tested with splashutils, not tested with bootsplash.

Cheers, JD.

-- System Information:
Debian Release: testing/unstable
 APT prefers unstable
 APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-beyond3
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

sysv-rc depends on no packages.

Versions of packages sysv-rc recommends:
ii  lsb-base  3.1-15 Linux Standard Base 3.1 init scrip

-- no debconf information
--- /etc/init.d/rc.old  2006-09-08 18:38:56.0 +0200
+++ /etc/init.d/rc  2006-09-17 12:11:33.0 +0200
@@ -77,13 +77,125 @@
 startup_progress() {
 $@
 if [ $SPLASH = true ] ; then
-step=$(($step + $step_change))
-progress=$(($step * $progress_size / $num_steps + $first_step))
-usplash_write PROGRESS $progress || true
+   step=$(($step + $step_change))
+   progress=$(($step * $progress_size / $num_steps + $first_step))
+   $debug usplash_write PROGRESS $progress || true
+   # If this is was the last step, reset step_change
+   [ $last_step_change = 1 ]  step_change=0
 fi
 }
 
 #
+# kill scripts - if 1st argument is countonly then nothing is executed
+#
+run_kill_scripts() {
+   if [ $last_step_change = 1 ]; then
+   local_step_change=0
+   else
+   local_step_change=1
+   fi
+   [ $1 = countonly ]  nkill=0
+   if [ $previous != N ]
+   then
+   # Run all scripts with the same level in parallel
+   CURLEVEL=
+   for s in /etc/rc$runlevel.d/K*
+   do
+   level=$(echo $s | sed 's/.*\/K\([0-9][0-9]\).*/\1/')
+   if [ $level = $CURLEVEL ]
+   then
+   continue
+   fi
+   CURLEVEL=$level
+   SCRIPTS=
+   for i in /etc/rc$runlevel.d/K$level*
+   do
+   # Check if the script is there.
+   [ ! -f $i ]  continue
+
+   #
+   # Find stop script in previous runlevel but
+   # no start script there.
+   #
+   suffix=${i#/etc/rc$runlevel.d/K[0-9][0-9]}
+   
previous_stop=/etc/rc$previous.d/K[0-9][0-9]$suffix
+   
previous_start=/etc/rc$previous.d/S[0-9][0-9]$suffix
+   #
+   # If there is a stop script in the previous 
level
+   # and _no_ start script there, we don't
+   # have to re-stop the service.
+   #
+   [ -f $previous_stop ]  [ ! -f $previous_start 
]  continue
+
+   # Stop the service.
+   SCRIPTS=$SCRIPTS $i
+   [ $1 = countonly ]  nkill=$(($nkill + 
$local_step_change))
+   case ${s##/etc/rc$runlevel.d/S??} in
+   gdm|xdm|kdm|reboot|halt)
+   local_step_change=0
+   last_step_change=1
+   ;;
+   esac
+   done
+   [ $1 != countonly ]  startup stop $SCRIPTS
+   done
+   fi
+}
+
+#
+# Start scripts - if 1st argument is countonly then nothing is executed
+#
+run_start_scripts() {
+   if [ $last_step_change = 1 ]; then
+   local_step_change=0
+   else
+   local_step_change=1
+   fi
+   [ $1 = countonly ]  nstart=0
+   CURLEVEL=
+   for s in /etc/rc$runlevel.d/S*
+   do
+   level=$(echo $s | sed 's/.*\/S\([0-9][0-9]\).*/\1/')
+   if [ $level = $CURLEVEL ]
+   then
+   continue
+   fi
+   CURLEVEL=$level
+   SCRIPTS=
+   for i in /etc/rc$runlevel.d/S$level*
+   do
+  

Bug#387894: [Pkg-sysvinit-devel] Bug#387894: sysv-rc: progress bar

2006-09-17 Thread Petter Reinholdtsen
[Jean-Damien Durand]
 abour progress bar, here are few fixes and suggestions.
 
 - in debug mode, probably the call to usplash_write should just be echoed

Sounds good.

 - the count of number of scripts executed is approximate v.s. what happens
   in reality (check if file exist, check of previous runlevel, etc.)
 - the computation of what fraction of the bar to fill is not guaranteed to
   reach 0 or 100, because of rouding issues (100/3, then multiplied again)

Right.  Sounds like a good idea too.

 Please find attached a patch for all these issues, where I
 factorized the call to kill and start script in order to avoid code
 duplication. I let you check and/or reject it, no pb!

The patch change a lot of indentation, making it hard to track what
are real changes and what are just tabs converted to spaces.  It would
be better with a patch without these irrelevant whitespace changes.

 Tested with splashutils, not tested with bootsplash.

Is it tested with usplash too?


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



Bug#387894: [Pkg-sysvinit-devel] Bug#387894: sysv-rc: progress bar

2006-09-17 Thread Jean-Damien Durand

Dear Petter,


The patch change a lot of indentation, making it hard to track what
are real changes and what are just tabs converted to spaces.  It would
be better with a patch without these irrelevant whitespace changes.


That is true.
The factorization of kill and start scripts in two dedicated functions 
(to not duplicate the code: one call to count the number of scripts, one 
call to execute them) will probably make diff  show a lot of lines 
anyway - I understand your point and can do nothing else but agree.
I'll have another look but if I do not post again a patch that's because 
I could not make it smaller.





Tested with splashutils, not tested with bootsplash.


Is it tested with usplash too?


No, with splashutils only. The $debug in front of the usplash_write will 
show very well what happens, and I believe this must work with usplash 
as well. Can somebody in your team do this thest?

Anyway you have a point; this must be tested.
I'll see what I can do in here (I have to install usplash; why not! I'll 
be happy to test it).


Cheers, JD.



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