devil-linux-develop Mailing List for Devil-Linux (Page 34)

Heiko Zuerker wrote:
> Quoting Andrzej Odyniec <an...@ma...>:
>>Heiko Zuerker wrote:
>>>Once the compile fails, simply try to continue with "make makefile" again.
>>>Sometimes the scripts fail for some weird reason, I think procmail was
>>>one of the ones which like to do that.
>>I done it some number of times and after resigned. Now process is building
>>ntop. Maybe 4 jobs is better than 8? Maybe conflicting dependences are not so
>>deep?
> There may be some dependencies we were not aware of or 2 script trying  
> to do the same thing at the same time.
> If you identify a 'problem child' let us know, maybe we can re-arrange  
> a few things.

Yes. With 4 parallel jobs all build process go without errors and created iso. 
But effect is the same, as I tried few days ago:

>> VFS: Mounted root (ext2 filesystem) readonly.
>> Freeing unused kernel memory: 428k freed
>>
>> ********************************************************************************
>> *                                                                              *
>> *                           Welcome to Devil-Linux                             *
>> *                                                                              *
>> ********************************************************************************
>>                           http://www.devil-linux.org/
>>
>> Version 1.3.5-2008-05-28
>> Kernel 2.6.25.4
>> Mounting SHM FS on /shm
>> waiting until usb-storage driver has initialized all devices ...
>> Creating devices in /dev
>>
>> Searching for configuration media
>> Checking for "etc-mods.tar.bz2" on "/dev/sda" ... mount failed
>> Checking for "etc-mods.tar.bz2" on "/dev/sda1" ... success!
>> loading configuration
>> Searching for Devil-Linux CD-ROM
>> Search list: /dev/hdb
>> checking /dev/hdb Found on /dev/hdb
>> Mounting SHM FS on /cdrom/shm
>> Unmounting  proc
>> Starting up final system...
>> aufs 20080519

...and all hangs. If I pull USB pendrive, there is no difference.
Heiko, how do You think, for what it waits in this momment?

Regards

Andrzej Odyniec

Quoting Andrzej Odyniec <an...@ma...>:

> Heiko Zuerker wrote:
>
>> Once the compile fails, simply try to continue with "make makefile" again.
>> Sometimes the scripts fail for some weird reason, I think procmail was
>> one of the ones which like to do that.
>
> I done it some number of times and after resigned. Now process is building
> ntop. Maybe 4 jobs is better than 8? Maybe conflicting dependences are not so
> deep?

There may be some dependencies we were not aware of or 2 script trying  
to do the same thing at the same time.
If you identify a 'problem child' let us know, maybe we can re-arrange  
a few things.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Heiko Zuerker wrote:

> Once the compile fails, simply try to continue with "make makefile" again.
> Sometimes the scripts fail for some weird reason, I think procmail was  
> one of the ones which like to do that.

I done it some number of times and after resigned. Now process is building 
ntop. Maybe 4 jobs is better than 8? Maybe conflicting dependences are not so 
deep?

Andrzej Odyniec

Once the compile fails, simply try to continue with "make makefile" again.
Sometimes the scripts fail for some weird reason, I think procmail was  
one of the ones which like to do that.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org



Quoting Andrzej Odyniec <an...@ma...>:

> Heiko Zuerker wrote:
>>> Oh and in order to use this functionality you have to use a new
>>> makefile parameter:
>>> make mrproper unpack prepare     <- as always
>>> make makefile        <- instead of "build install iso"
> I wrote:
>> Now all is clear for me. So I try it now. I will set -j1 , JOBS to 8 and run
>> full process again this night. Tomorow I will check total time and will
>> report. It is thinkable, some compilation phases are dependent and must be
>> done one aftter one... but this isn't elegant
>
> So... there is no success. After one hour there are build errors. Maybe
> dependences between packages are unhappy when we do parallel builds?
>
> I will reduce JOBS to 4 (as You have) and repeat build process, first time
> from mrpropper and if no success, will try again from clean system.
>
> Regards
>
> Andrzej Odyniec
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Heiko Zuerker wrote:
>>Oh and in order to use this functionality you have to use a new  
>>makefile parameter:
>>make mrproper unpack prepare     <- as always
>>make makefile        <- instead of "build install iso"
I wrote:
> Now all is clear for me. So I try it now. I will set -j1 , JOBS to 8 and run 
> full process again this night. Tomorow I will check total time and will 
> report. It is thinkable, some compilation phases are dependent and must be 
> done one aftter one... but this isn't elegant

So... there is no success. After one hour there are build errors. Maybe 
dependences between packages are unhappy when we do parallel builds?

I will reduce JOBS to 4 (as You have) and repeat build process, first time 
from mrpropper and if no success, will try again from clean system.

Regards

Andrzej Odyniec

Heiko Zuerker wrote:
> it's mostly the Makefiles of the various packages which don't like to  
> be compiled with -jX
> 
> We introduced a new parameter in DL1.3 CONFIG_PARALLEL_JOBS
> I have this set to 4 on my dual core box, which make it run quite nicely.
> It basically let's the DL build system run X scripts in parallel,  
> which seems to work better.
> Every once in a while I have a script fail, I just restart it and keep going.
> 
> Oh and in order to use this functionality you have to use a new  
> makefile parameter:
> make mrproper unpack prepare     <- as always
> make makefile        <- instead of "build install iso"

Now all is clear for me. So I try it now. I will set -j1 , JOBS to 8 and run 
full process again this night. Tomorow I will check total time and will 
report. It is thinkable, some compilation phases are dependent and must be 
done one aftter one... but this isn't elegant

Thanks, Heiko

Andrzej Odyniec

Hey,

it's mostly the Makefiles of the various packages which don't like to  
be compiled with -jX

We introduced a new parameter in DL1.3 CONFIG_PARALLEL_JOBS
I have this set to 4 on my dual core box, which make it run quite nicely.
It basically let's the DL build system run X scripts in parallel,  
which seems to work better.
Every once in a while I have a script fail, I just restart it and keep going.

Oh and in order to use this functionality you have to use a new  
makefile parameter:
make mrproper unpack prepare     <- as always
make makefile        <- instead of "build install iso"

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org



Quoting Andrzej Odyniec <an...@ma...>:

> Heiko Zuerker wrote:
>>> 1. In build configuration option CONFIG_PMAKE in make menuconfig has
>>>    a limit of 2. I observed on my Core Quad that compilation is faster
>>>    when CONFIG_PMAKE=4. I think, better is set this limit to 4.
>> Many programs have trouble with this, that's why we limited it to 2.
>> DL 1.3 has a better options which is much more stable.
> I'm not sure, we are talking about this same? I think about build process of
> last DL 1.3 development and about setting in "Build Configuration" |  
> "Parallel
> Compile Jobs" which is recorded as CONFIG_PMAKE option in build/.config and
> limits number of cc compilations simultaneously. This option is transferred
> mainly to -j parameter of make command when compiling kernel or packages.
>
> I understand that more then 2 cc parallel processes on single CPU enhances
> process scheduling overdraft and sometimes is slower, than one process after
> one. And 4 parallel processes on single CPU can be much slower.
>
> But on 4 CPU cores in compiling/building machine if I set CONFIG_PMAKE option
> to 4, complete build from unpack to iso take 2h30' but if this option allows
> only 2 cc processes simultaneously, total time is over 3h.
>
> I unterstand difference between one and two processes, because in parallel
> computing coprocesses must be independent or synchronised. But if You allow
> for 2 parallel processs, what difference for 4 parallel cc's? I think cc
> processes are from definition independent.
>
> But, if You are sure You know about negative experience with parallel
> compilations, OK. I accept this. I work in computer science from 70s
> (beginning from CDC Cyber 7000) and I know many miracles in computing. :-)
>
> Regards
>
> Andrzej Odyniec
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Heiko Zuerker wrote:
>>1. In build configuration option CONFIG_PMAKE in make menuconfig has
>>    a limit of 2. I observed on my Core Quad that compilation is faster
>>    when CONFIG_PMAKE=4. I think, better is set this limit to 4.
> Many programs have trouble with this, that's why we limited it to 2.
> DL 1.3 has a better options which is much more stable.
I'm not sure, we are talking about this same? I think about build process of 
last DL 1.3 development and about setting in "Build Configuration" | "Parallel 
Compile Jobs" which is recorded as CONFIG_PMAKE option in build/.config and 
limits number of cc compilations simultaneously. This option is transferred 
mainly to -j parameter of make command when compiling kernel or packages.

I understand that more then 2 cc parallel processes on single CPU enhances 
process scheduling overdraft and sometimes is slower, than one process after 
one. And 4 parallel processes on single CPU can be much slower.

But on 4 CPU cores in compiling/building machine if I set CONFIG_PMAKE option 
to 4, complete build from unpack to iso take 2h30' but if this option allows 
only 2 cc processes simultaneously, total time is over 3h.

I unterstand difference between one and two processes, because in parallel 
computing coprocesses must be independent or synchronised. But if You allow 
for 2 parallel processs, what difference for 4 parallel cc's? I think cc 
processes are from definition independent.

But, if You are sure You know about negative experience with parallel 
compilations, OK. I accept this. I work in computer science from 70s 
(beginning from CDC Cyber 7000) and I know many miracles in computing. :-)

Regards

Andrzej Odyniec

Quoting Andrzej Odyniec <an...@ma...>:

> Hi,
>
> I have two suggestions:
>
> 1. In build configuration option CONFIG_PMAKE in make menuconfig has
>     a limit of 2. I observed on my Core Quad that compilation is faster
>     when CONFIG_PMAKE=4. I think, better is set this limit to 4.

Many programs have trouble with this, that's why we limited it to 2.
DL 1.3 has a better options which is much more stable.

> 2. In default kernel config CONFIG_SCSI_MULTI_LUN is traditionally unset.
>     In past SCSI devices with multiple Logical Unit Numbers was very rare,
>     legacy rather, as created for multiple MTUs connected to single  
> controller.
>
>     But now SCSI logic is used to all USB drives and there are pen drive's
>     with flash card reader and separate built-in memory (i.e. Kingston
>     DataTraveler Reader) as separate LUNs. If this kernel option is unset,
>     second LUN is invisible for Devil-Linux an it is impossible boot from
>     this flash card and read configuration from it.
>
>     Especially, in Windows devices like this are supported without problems.
>
>     So I suggest to set this option in default kernel configuration
>     in Devil-Linux to CONFIG_SCSI_MULTI_LUN=y

good idea

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Hi,

I have two suggestions:

1. In build configuration option CONFIG_PMAKE in make menuconfig has
    a limit of 2. I observed on my Core Quad that compilation is faster
    when CONFIG_PMAKE=4. I think, better is set this limit to 4.

2. In default kernel config CONFIG_SCSI_MULTI_LUN is traditionally unset.
    In past SCSI devices with multiple Logical Unit Numbers was very rare,
    legacy rather, as created for multiple MTUs connected to single controller.

    But now SCSI logic is used to all USB drives and there are pen drive's
    with flash card reader and separate built-in memory (i.e. Kingston
    DataTraveler Reader) as separate LUNs. If this kernel option is unset,
    second LUN is invisible for Devil-Linux an it is impossible boot from
    this flash card and read configuration from it.

    Especially, in Windows devices like this are supported without problems.

    So I suggest to set this option in default kernel configuration
    in Devil-Linux to CONFIG_SCSI_MULTI_LUN=y

Regards

-- 
Andrzej Odyniec

Serge Leschinsky:
>>Thanks, Serge. So I will try this and will inform about my tries.
> Please, check the scripts I've attached.

But... I have NOT any success. I started soome days ago. I found this script s 
on CVS distribution -- thanks. I did some number of compilations.

But... even after compilation from completely clean system I can't obtain 
working system. I will compile again, but please, look what I see on SOL 
console when booting system:

> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 428k freed
> 
> ********************************************************************************
> *                                                                              *
> *                           Welcome to Devil-Linux                             *
> *                                                                              *
> ********************************************************************************
>                           http://www.devil-linux.org/
> 
> Version 1.3.5-2008-05-27
> Kernel 2.6.25.4
> Mounting SHM FS on /shm
> waiting until usb-storage driver has initialized all devices ...
> Creating devices in /dev
> 
> Searching for configuration media
> Checking for "etc-mods.tar.bz2" on "/dev/sda" ... mount failed
> Checking for "etc-mods.tar.bz2" on "/dev/sda1" ... success!
> loading configuration
> Searching for Devil-Linux CD-ROM
> Search list: /dev/hdb
> checking /dev/hdb Found on /dev/hdb
> Mounting SHM FS on /cdrom/shm
> Unmounting  proc
> Starting up final system...
> aufs 20080519

And in this point all stops!

I checked with initramfs and result is this same.

As to now I changed some packages (shorewall).
Now I will compile again, from clean system and with default .config too.

Regards

Andrzej Odyniec

> >> Yes, it's enough. I had modified .config file and changed
> >> "CONFIG_INITRD_FS=EXT2" to "CONFIG_INITRD_FS=INITRAMFS"  before "make clean iso".
> > 
> > Should we change the default profile too?
> Since only a part of the job was done, I consciously did not touch the profiles.
> I'm planning to modify (if necessary) "custom-cd" and "install-on-usb" before we
> start to use that option as a default one. I'm not sure but suspect that current
> "install-on-usb" will break booting DL in case of initramfs. So, let's leave it
> as it is for some time.

OK, that makes sense.

> >> PS. I can't see the changes in the "prepare.config"...  I added "INITRAMFS" as
> >> an option for initrd.
> > 
> > I don't understand.  I see INITRAMFS as an option in 'make menuconfig'.
> "cvs diff " shows that all changes are on-site. It looks like I haven't got the
> message from Devil-linux-commit...

I got this prepare.config dl-commit email on the 19th:

...
-menu_add "Build Configuration" list "InitRD Filesystem" CONFIG_INITRD_FS EXT2
+menu_add "Build Configuration" list "InitRD Filesystem" CONFIG_INITRD_FS EXT2 INITRAMFS
...

 - BS

Bruce Smith wrote:
>> Yes, it's enough. I had modified .config file and changed
>> "CONFIG_INITRD_FS=EXT2" to "CONFIG_INITRD_FS=INITRAMFS"  before "make clean iso".
> 
> Should we change the default profile too?
Since only a part of the job was done, I consciously did not touch the profiles.
I'm planning to modify (if necessary) "custom-cd" and "install-on-usb" before we
start to use that option as a default one. I'm not sure but suspect that current
"install-on-usb" will break booting DL in case of initramfs. So, let's leave it
as it is for some time.

> 
>> PS. I can't see the changes in the "prepare.config"...  I added "INITRAMFS" as
>> an option for initrd.
> 
> I don't understand.  I see INITRAMFS as an option in 'make menuconfig'.
"cvs diff " shows that all changes are on-site. It looks like I haven't got the
message from Devil-linux-commit...

--
Serge

> Yes, it's enough. I had modified .config file and changed
> "CONFIG_INITRD_FS=EXT2" to "CONFIG_INITRD_FS=INITRAMFS"  before "make clean iso".

Should we change the default profile too?

> PS. I can't see the changes in the "prepare.config"...  I added "INITRAMFS" as
> an option for initrd.

I don't understand.  I see INITRAMFS as an option in 'make menuconfig'.

 - BS

Bruce Smith wrote:
>> - initial INITRAMFS support
>>
> Hey Serge,  Is a "make clean iso" good enough to try your changes?
> (or should I start over with a mrproper?)

Yes, it's enough. I had modified .config file and changed
"CONFIG_INITRD_FS=EXT2" to "CONFIG_INITRD_FS=INITRAMFS"  before "make clean iso".

PS. I can't see the changes in the "prepare.config"...  I added "INITRAMFS" as
an option for initrd.

--
Serge

> - initial INITRAMFS support
> 
Hey Serge,  Is a "make clean iso" good enough to try your changes?
(or should I start over with a mrproper?)

 - BS

Bruce Smith wrote:

> Just because someone uses something, they are not necessarily familiar
> with the technology.  :-)
 Yes, you are right. :-) There are a lot of habitual things about which
internals I know nothing....

> I could state tons of examples of how people use technology every day,
> but are not familiar with the technology.  Looking at my desk, I'm using
> a flat panel monitor and an optical mouse right now.  I know how to buy
> them, connect them to my computer, and USE them, but I have now idea how
> they actually work internally.  ;-)
If I have a chance to invite you for several pints of beer and you still be
interested in theoretical basis of LCD panel and optical mouse operation I'll be
happy to share my knowledge!  :-)))


> BTW, if your system boots and runs fine with initramfs, I'm OK if you
> check in the changes.  We can work through any bugs that come up.
> (that's what I did with aufs! :)  1.3 is still a development release.
Certainly. My system boots correctly. The current realization is a bit more
complicated than could be, but it's the result of backward compatibility with
initrd.

Well, if nobody has objections I'll check in the initramfs support patch.

--
Serge

> >> I've implemented initramfs support for DL (only for syslinux yet). This feature
> >> is optional and breaks nothing but I'd like to have a tiny round of testing
> >> before checking in.
> > 
> > I'm not familiar with initramfs.  Explain?
> I'm sure you are familiar ;-) because all current Linux distributions uses it.

Just because someone uses something, they are not necessarily familiar
with the technology.  :-)

I could state tons of examples of how people use technology every day,
but are not familiar with the technology.  Looking at my desk, I'm using
a flat panel monitor and an optical mouse right now.  I know how to buy
them, connect them to my computer, and USE them, but I have now idea how
they actually work internally.  ;-)

> To not confuse you my poor English, I copied the information from the wiki page:
> 
> http://en.wikipedia.org/wiki/Initrd

Hum, I wonder if wikipedia explains how flat panel monitors and optical
mice work ...  Thanks!  ;-)

BTW, if your system boots and runs fine with initramfs, I'm OK if you
check in the changes.  We can work through any bugs that come up.
(that's what I did with aufs! :)  1.3 is still a development release.

 - BS

Bruce Smith wrote:
>> I've implemented initramfs support for DL (only for syslinux yet). This feature
>> is optional and breaks nothing but I'd like to have a tiny round of testing
>> before checking in.
> 
> I'm not familiar with initramfs.  Explain?
I'm sure you are familiar ;-) because all current Linux distributions uses it.
To not confuse you my poor English, I copied the information from the wiki page:

http://en.wikipedia.org/wiki/Initrd

Initramfs in comparison with initrd

initramfs is an alternative, simpler method of having files available at boot
time without having them in a persistent mountable filesystem.

With initrd, the kernel creates a memory-backed block device, loads it with data
from a file, then mounts the device to create a filesystem image. With
initramfs, the kernel creates a filesystem image directly from a file, without
involving any block device. [2]

With initrd, the file contains a filesystem in on-disk format, while with
initramfs, the file contains a compressed cpio archive. That means it is more
convenient for a system builder to create and modify the contents of the
filesystem with initramfs. With initramfs, there is no mounting, unmounting, and
loop device involved. There is no privileged system operation at all.

With initramfs, the filesystem is typically a tmpfs, shmfs, or ramfs filesystem.
These filesystem types did not exist when initrd became popular, and that
history is usually the reason that initrd is used instead of initramfs.

The boot-time operation of initrd is slightly simpler than that of initramfs.
With initrd, the boot loader copies the filesystem directly from the file to the
memory that backs a ramdisk, then the kernel need only define a ramdisk over
that same memory and do a standard filesystem mount. With initramfs, there are
equivalent steps to get the cpio archive into memory and create a filesystem
image, plus an additional procedure to unpack the cpio archive into the new
filesystem image. The kernel must know the cpio archive format. Some of the
computation that happens at build time with initrd happens at boot time with
initramfs.

--
Serge

> I've implemented initramfs support for DL (only for syslinux yet). This feature
> is optional and breaks nothing but I'd like to have a tiny round of testing
> before checking in.

I'm not familiar with initramfs.  Explain?

 - BS

Hello,

I've implemented initramfs support for DL (only for syslinux yet). This feature
is optional and breaks nothing but I'd like to have a tiny round of testing
before checking in.

So, volunteers are wanted!

--
Serge

Andrzej Odyniec wrote:
> Serge Leschinsky:
> 
>> http://www.splintered.net/sw/flow-tools/
>> I think I can add this tool (anyway I have been going to do it for a long time!).
> 
> Thanks, Serge. So I will try this and will inform about my tries.

Please, check the scripts I've attached.

Source: http://flow-tools.googlecode.com/files/flow-tools-0.68.4.tar.bz2

Thank you in advance,

--
Serge

Serge Leschinsky:

> http://www.splintered.net/sw/flow-tools/
> I think I can add this tool (anyway I have been going to do it for a long time!).

Thanks, Serge. So I will try this and will inform about my tries.

Regards

Andrzej Odyniec

> > - Upgrade src: lm-sensors-3.0.1
> >   Upgrade script: lm-sensors (attach)
> >   Remove src/script: i2c and sysfsutils (www.lm-sensors.org/wiki/Download)
> Hm... As far as I know lm-sensors-3 and i2c are different packages 
> now. Have I understood you correctly that you suggest to exclude i2c 
> from DL? Not update and keep it as a different package but exactly remove?

>From wiki url:
- You no longer need to install the libsysfs library.
......
- Linux 2.6 users do not need to get this i2c package, it's already part of
the kernel tree.

The problem (now) is:
- Most third party monitoring applications do not yet work with the library in
this package

In Devil the problem there is for net-snmp (there is a patch for new lm-sensor)


> > - Error in pptp-patches for 2.6.24
> >   Upgrade src (attach), soon for kernel 2.6.25
> ....
> > - Error in rp-pppoe
> Is it the consequence of pptp-patches for 2.6.24?

I don't remember and I search old LOG but I must compile 1.2 and I drop all
but I don't think.
Patch is same to 2.6.23 but apply to 2.6.24 without other code


> > - Error in RPM. It makes sense to take this?
> I think we may neglect that.
> 
> > 
> > - Error in portslave. One radiusclient.h is in ppp but there are many many
> > errors. Maybe install old radiusclient pack?
> Portslave is a troglodytic package. I'm not sure we have to spent 
> our time for adapting it.

I agree


> > - Error in eagle-usb. It's based an old kernel (view configure). Try to
> > substitute version.h with utsrelease.h but many many errors.
> Hm... Probably we should check the project status and if it's a dead 
> project - disable/remove it.

Module is very old (three years old if I remember ...)


> > - kid requirement for sagator (for webq service)
> >   New src: kid-0.9.6.tar.gz
> >   New script: kid (attach)
> >   Upgrade script: sagator
> >   New requirement: kid.requirement.tar.bz2 (attach)
> >   + elementtree-1.2.6-20050316.tar.gz
> >   + cElementTree-1.0.5-20051216.tar.gz
> Will be tested soon.

Compile all ok but I don't test


Alby

Hi Andrzej,

Andrzej Odyniec wrote:
> Hi Guys,
> 
> What do You use to collect Netflow on Devil-Linux, i.e. netflow from fprobe?
I may share my experience. I use flow-tools for several years and I strongly
recommend flow-capture from this package as a flow collector.

> I'm looking for method to logging netflow in Devil-linux and can't find. I'm 
> used sometime netacct but now netacct-mysql is not logging flows, but only 
> RRD. It is not sufficient.
> 
> I found NNFC, but this package is not present on Devil-Linux. Maybe is need to 
> append tool for collect netflow into log files to external analysis.
Agree. What tool? :-)

> Any suggestions?
http://www.splintered.net/sw/flow-tools/

I think I can add this tool (anyway I have been going to do it for a long time!).

--
Serge