Page MenuHomePhabricator libgtk-3-common all 3.22.11-1 hash mismatch
Closed, InvalidPublic


Rebuilds of Toolforge stretch Docker images are failing due to a mismatch of package and manifest checksums for libgtk-3-common

Get:100 stretch/main amd64 libgtk-3-common all 3.22.11-1 [3416 kB]
Err:100 stretch/main amd64 libgtk-3-common all 3.22.11-1
  Hash Sum mismatch
  Hashes of expected file:
   - SHA256:8544d0744e11408545a54cdd028f87511995061eed1d411dba45d42028077435
   - MD5Sum:4092c06594442b20de7eaebfc32b9731 [weak]
   - Filesize:3415880 [weak]
  Hashes of received file:
   - SHA256:4a8daa1d6af21eb2d4e36c6c22e5261b17e9e9ca299adde2d79e4398a5198238
   - MD5Sum:ea21fa8cd2c2d3d31c68f6cfdfe382d2 [weak]
   - Filesize:1075040 [weak]
  Last modification reported: Fri, 24 Mar 2017 04:44:34 +0000

Event Timeline

bd808 created this task.Feb 12 2020, 10:39 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 12 2020, 10:39 PM
bd808 added a subscriber: faidon.

@faidon did some investigation and found that this may have been caused by upstream repo state rather than our mirror being out of sync. I am re-running the tediously long container builds that showed this failure twice previously to see if it has been fixed. If not I hope to proved a more narrow reproduction case which may help in identifying the underlying problem.

I think we can rule out a change in the upstream repository; initially I had the hunch that this could be caused by a stale mirror after the latest Stretch point release, but nothing changed to that deb (libgtk-3-common) since 24 Mar 2017 when it was uploaded initially to Debian, the expected hashes are also the same of what's currently found on the mirrors.

But the file size appears to be truncated? It reports 1075040 bytes vs the actual 3415880 bytes as found on

jbond triaged this task as Medium priority.Feb 13 2020, 11:47 AM
bd808 closed this task as Invalid.Feb 13 2020, 4:04 PM

But the file size appears to be truncated? It reports 1075040 bytes vs the actual 3415880 bytes as found on

Yes, this seems like the problem. The 3rd run of the container builds I did worked fine. We can close this as non-repeatable, but I will try to keep an eye out for other problems that could be caused by network interruptions when calling public URLs from inside Toolforge/Cloud VPS.