Michael Renner <[EMAIL PROTECTED]> wrote: Hi,
> Uhm, if I've got a logfile full of MCE entries after (e.g.) returning > from a weeks vacation a timestamp with a granularity of 5 minutes is That'd be 10 minutes, not 5, and it can be even more than that under some circumstances. > better than none, right? I can understand that Andi doesn't want to > implement this for the given reasons but the cron hackaround is > useful, will help people and should be robust enough (the only problem > I could see would be exceeding the storage size of the variables of > the shell when storing the log messages, but this is highly Pipe mcelog output through annotate-output (from devscripts) to avoid that :) > unlikely). Adding a hint that the timestamps are only estimates > (either in the log or the README) or letting the user choose if he > wants "inaccurate" timestamps should mitigate any user complaints (if > there should be any. I pretty much doubt it). Nobody reads the damn README, so that's completely useless, and I can already see the bug reports coming in claiming that the timestamp isn't accurate. >> So, closing this bug as a feature request which unfortunately can't be >> implemented. > > I'd opt for reconsidering that, cutting usability because the gathered > information isn't 100% accurate isn't good practice. I'll include a suggestion to install the devscripts package and edit the cron file to use annotate-output in the next upload, for people who actually do read the README. You probably know that already, but just in case: you can edit the cron file, it's tagged as a conffile. JB. -- Julien BLACHE <[EMAIL PROTECTED]> | Debian, because code matters more Debian & GNU/Linux Developer | <http://www.debian.org> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
