Page MenuHomePhabricator
Create Task
Maniphest T245071

mirrors.wikimedia.org libgtk-3-common all 3.22.11-1 hash mismatch
Closed, InvalidPublic
Actions

Description

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

Get:100 http://mirrors.wikimedia.org/debian stretch/main amd64 libgtk-3-common all 3.22.11-1 [3416 kB]
Err:100 http://mirrors.wikimedia.org/debian 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 project: cloud-services-team (Kanban).Feb 13 2020, 12:08 AM
bd808 moved this task from Inbox to Watching on the cloud-services-team (Kanban) board.Feb 13 2020, 12:11 AM
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.

MoritzMuehlenhoff added a comment.Feb 13 2020, 6:39 AM

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 mirrors.wikimedia.org

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
In T245071#5879649, @MoritzMuehlenhoff wrote:

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

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.

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL