severity 573232 normal tags 573232 upstream forwarded 573232 ra...@podgorny.cz thanks
On Tue, Mar 9, 2010 at 11:42 PM, Martin Steigerwald <mar...@lichtvoll.de> wrote: > Severity: grave > Justification: causes non-serious data loss "grave" and "non-serious"? > I don't know when exactly, maybe today I updated uptimed and > somehow either debconf didn't ask me whether I'd like > uptimed.conf being overwritten or I accidently answered yes > to this question. This set maxrecords from zero to 25. > > And uptimed truncated the log. I first thought I lost the other I believe this is the expected behaviour. > entries upon a recent crash of the OSS radeon X.org driver, but > uptimed truncated the file I restored from the backup again > and again. Eventually I wondered that uptimed might truncate it > due to limited maxrecords settings. > > However it happened that the maxrecords setting changed, it may > really well be that I accidentally answered a question, but I > remember I did not. Well however... > > IMHO uptimed should not truncate the records file to the > maxrecords setting when it was longer before. This should > only be done manually to avoid accidental data loss of > uptime history. Either by invoking some tool or by using > an editor to delete the lines manually. Well to me that looks very much like a wishlist item. Your perception of the "correct" behaviour may actually be different from others, in particular upstream's. I for one find it very sensible that if I reduce maxrecords the record file will be truncated. You're supposed to know what you're doing when setting up a piece of software. The only potential bug I could see here would be if upgrading uprecords actually overwrites the records file, but I'm not aware of such a bug so far. > Truncating the file also led to a misleading %up value. I had > more than 91% and then it was about 60%. Even on reducing > max records, when there are more records already saved in the > records file this information should not be lost without > manual intervention. uptimed could still only add records > up to maxrecords, but it should leave existing records > beyond maxrecords in the file. I disagree. I'll leave it to the upstream maintainer to settle this; depending on his feedback I might requalify the bug as "wishlist". > I can report this upstream as well if you wish. Or maybe > it could be forwarded? CC'ing upstream > -- System Information: > Debian Release: squeeze/sid > APT prefers testing > APT policy: (450, 'testing'), (400, 'unstable'), (101, 'experimental') > Architecture: i386 (i686) > > Kernel: Linux 2.6.32.8-tp42-toi-3.0.99.49 (PREEMPT) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages uptimed depends on: > ii debconf [debconf-2.0] 1.5.28 Debian configuration management > sy > ii libc6 2.10.2-6 Embedded GNU C Library: Shared > lib > ii libuptimed0 1:0.3.16-3.1 Library for uptimed > > uptimed recommends no packages. > > uptimed suggests no packages. > > -- debconf information: > * uptimed/mail/do_mail: Both > * uptimed/mail/address: r...@localhost > * uptimed/interval: 43200 > * uptimed/mail/milestones_info: > * uptimed/maxrecords: 25 HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
