Hi,
I've reported it before that the debian package installer fails on minimal systems during the re-dumping of pike modules. Before, dumping by hand would mostly resolve the issue, however currently I'm working on such a system where the (I think the same) failure also occurs by doing the dumping by hand.
However the failure notice of the dumping process is not very helpfull:
root@iota:/# pike7.8 -x dump -r /usr/lib/pike7.8 Alarm clock root@iota:/# echo $? 142 root@iota:/# pike7.8 -x dump --verbose -r /usr/lib/pike7.8 #### /usr/lib/pike7.8: Is a directory (dumping recursively). #### /usr/lib/pike7.8/7.0: Is a directory (dumping recursively). #### /usr/lib/pike7.8/7.0/include: Is a directory (dumping recursively). #### /usr/lib/pike7.8/7.0/modules: Is a directory (dumping recursively). #### /usr/lib/pike7.8/7.0/modules/__default.pmod: Dumped. #### /usr/lib/pike7.8/7.0/modules/Stack.pmod: Dumped. ... (a few more modules are being dumped) #### /usr/lib/pike7.8/7.4/modules/Sql.pmod/sql.pike: Dumped. #### /usr/lib/pike7.8/7.4/modules/__default.pmod: Dumped. #### /usr/lib/pike7.8/7.4/modules/Protocols.pmod: Is a directory (dumping recursively). Alarm clock
any thoughts?
The "Alarm clock" means that dumping something took more than 60 seconds. In this case the "something" seems to be the 7.4/modules/Protocols.pmod directory, which only contains one module. Is it conceivable that dumping this module actually takes more than 60 seconds on this system? When running with --verbose, how much time on average passes between each line is printed?
Other possibilities would be that there is an actual bug, either
1) Dumping hangs for some reason
or
2) alarm() doesn't work correctly on this system
You could try altering the alarm(60) in dump.pike, either increasong the timeout or removing the call altogether, to see what happens.
pike-devel@lists.lysator.liu.se