On 2012-01-22 17:44 +0100, Georgios M. Zarkadas wrote:
> Στις 21-01-2012, ημέρα Σαβ, και ώρα 14:00 +0100, ο/η Sven Joachim
> έγραψε:
>> On 2012-01-16 17:58 +0100, Sven Joachim wrote:
>>
>> > It seems that we need a migration path to the single md5sums file, since
>> > (with backup-manager from git master) cron spams me with mails
>> > containing messages like these:
>> ...
>> > After BM_ARCHIVE_TTL days this will hopefully stop, but it is still not
>> > acceptable to annoy everyone with those messages.
>>
>> There is another problem that applies to upstream as well: md5sum hashes
>> for old backups are not removed from $MD5FILE when the archives
>> themselves are deleted....
>
> Regarding the first, the possible solutions are:
>
> * Lower the severity of this condition to 'info' instead of 'warning'.
> Needs to patch upstream, but it is just a one-line patch.
This probably makes some sense, if only because people using upstream
releases will eventually also be affected by the problem.
> * Launch a background process during the package's postinst script
> to calculate the md5 hash of existing archives and store them to
> the md5 sums file. This can be tricky; we don't know the size of
> archives beforehand, nor can we warranty that the process will not
> get interrupted.
Sounds no good. I was thinking more about something simple like
cat *-20*.md5sums > $MD5FILE
In both cases there is the disadvantage that it might not catch the
md5sums file of a backup-manager process that is running during the
upgrade, since that file is likely only created after we've finished.
> * Modify just the cron file to grep out that message. That means to
> add a '| grep -v "Unable to find the md5 hash"' to the template
> and also to dynamically examine and modify any existing cronfile
> during the postinst.
This is really evil and won't work in non-English locales anyway.
> I am inclined to do the first of the above. The message is only issued
> by the 'purge_duplicate_archives' function, thus the only harm that a
> missing md5 hash can make is to miss a possible opportunity to free some
> disk space before the BM_ARCHIVE_TTL period expires. 'Info' seems to me
> a more appropriate severity level for such minor issues.
Another place where the md5sums files are used is the burning facility
if BM_BURNING_CHKMD5 is set to "true". Have you investigated that yet?
> Regarding the second issue, I believe the best way to solve it is to
> ship a new monthly cronjob that uses the largest of BM_ARCHIVE_TTL and
> BM_UPLOAD_*TTL settings, then removes all lines with older date from the
> md5 sums file. It is premature to try to patch the upstream code,
> because IMO the whole metadata subject needs a mild redesign.
In the light of this, how about disabling the single md5sum feature in
the next upload and getting it into better shape upstream first?
Cheers,
Sven
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
