Hi,

if i shall place a bet, then i'd say the checksum mismatch in
  https://sources.debian.org/src/jigdo/0.7.3-5/src/mkimage.cc/#L508
is where the message should be issued:

          ...
          case JigdoDesc::MATCHED_FILE: {
            /* If file present in cache, copy its data to image, if
               not, copy zeroes. if check==true, verify MD sum match.
               If successful, turn MatchedFile into WrittenFile. */
            ...
            if (mfile == 0 || self->md5() != *(mfile->getMD5Sum(cache))) {
              // Write right amount of zeroes

Here it should say something. The file was found but the checksum does not
match. (Still riddling under which circumstances mfile would be 0.)

              memClear(buf, readAmount);
              while (*img && toWrite > 0) {
                size_t n = (toWrite < readAmount ? toWrite : readAmount);
                writeBytes(*img, buf, n);
                reportBytesWritten(n, off, nextReport, totalBytes, reporter);
                toWrite -= n;
              }
              if (result == 0) result = 1; // Soft failure
            } else {
              /* Copy data from file to image, taking care not to
                 write beyond toWrite. */
              int status = fileToImage(img, *mfile, *self, checkMD5,
                  imageInfo.blockLength(), reporter, buf, readAmount, off,
                  nextReport, totalBytes);
              toCopy.pop();
              if (result < status) result = status;
              if (status == 0) { // Mark file as written to image
              ...

Function fileToImage() does its own checksum verification, but i believe to
see in
  https://sources.debian.org/src/jigdo/0.7.3-5/src/mkimage.cc/#L407
that it would issue a message if this verification failed:

    } else if (checkMD5
               && (md.finish() != matched.md5()
                   || (rsyncLen > 0 && rs != matched.rsync()))) {
      err = subst(_("Error: `%1' does not match checksum in template data"),
                  fileName);
    }

So if the check in fileToImage() issues an error message, then a MD5
mismatch of the whole file should issue such a message, too.
That much is clear.
But i can only hope that this is the place where in my case the files
got rejected.

I hacked myself a jigdo-file with
===========================================================================
--- src/mkimage.cc.orig 2017-12-16 16:24:10.297866522 +0100
+++ src/mkimage.cc      2017-12-16 16:55:49.369873692 +0100
@@ -507,6 +507,16 @@ namespace {
                   (mfile != 0 ? mfile->leafName() : ""), toCopy.size());
             if (mfile == 0 || self->md5() != *(mfile->getMD5Sum(cache))) {
               // Write right amount of zeroes
+
+              // ts B71216 : Experimental (especially the mfile message)
+              if (mfile == 0) {
+                reporter.error(_("mfile == 0 with matched file"));
+              } else {
+                string err = subst(_("MD5 mismatch with matched file `%1'"),
+                                   mfile->leafName());
+                reporter.error(err);
+              }
+
               memClear(buf, readAmount);
               while (*img && toWrite > 0) {
                 size_t n = (toWrite < readAmount ? toWrite : readAmount);
===========================================================================
and tried to provoke the messages.

But Philip Hands must have been faster with repairing the package files.
My unfinished DVD-2 simply got completed.
  OK: Checksums match, image is good!   

I will probably try to fake a mismatch later this weekend.
(Something like hardcoding a package name into my hack and throwing
 artificial mismatch during a full download. I should have made a copy
 of my incomplete DVD-2. Now each try will last 20 minutes and Telekom
 will begin to hate me.)


Have a nice day :)

Thomas

Reply via email to