I use the pcfclock package to access my dcf77 module. after updating to kernel 2.6.12-r10, (and also remerging pcfclock) the pcfdate application _sometimes_ doesn't find the clock. This happens more often from within bash scripts or after having the bash sleep for a while. Reproducible: Always Steps to Reproduce: 1. login 2. # sleep 10 && pcfdate -v Actual Results: marvin ~ # sleep 10 && pcfdate -v pcfdate: /dev/pcfclock0: No such device pcfdate: /dev/pcfclock1: No such file or directory pcfdate: /dev/pcfclock2: No such file or directory Expected Results: marvin ~ # pcfdate -v Tue Sep 13 15:51:43 2005 - DST: Yes - Sync: Ok - Battery: Ok I first thought this had something to do with some other driver accessing the parallel port, so I tried to deactivate anything in the kernel which could be doing this -- ide-over-parport, iomega-drivers, ... Still, the behavior didn't change.
This ebuild is missing metadata.xml
sounds like an incompatibility with your newer kernel ... you should probably try downgrading and see if it fixes the issue you could also try building the package by hand rather than using the ebuild, sometimes that exposes a problem in the ebuild if none of these things work you really should contact upstream: http://www-stud.ims.uni-stuttgart.de/~voegelas/pcf.html
Try w/ 0.44-r3, please.
well, this is a general issue with this hardware and the stupid protocol it uses via parport, not the kernel (I know this, because I own this clock also). But it's not really a problem. ntpd works w/o problems. Just syslog is populated with these warnings. Ignore or filter them...
