Closed Bug 1410775 Opened 2 years ago Closed 2 years ago

servo-vcs-sync: failure due to metadata mismatch

Categories

(Developer Services :: Servo VCS Sync, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: glob, Assigned: gps)

Details

sequence of events:

2017-10-20T18:49:30
hg> pulling https://hg.mozilla.org/projects/converted-servo-linear into /home/servo-sync/firefox-overlay/.hg/hg.mozilla.org__projects__converted-servo-linear
hg> searching for changes
hg> adding changesets
hg> adding manifests
hg> adding file changes
hg> added 1 changesets with 7 changes to 7 files
hg> 35889bece1fe already processed as d903497170f2; skipping 10399/10400 revisions
hg> ee57178ea85a -> 196206f129ef: servo: Merge #18941 - Move nsstring from gecko into servo/support/gecko/nsstring (from mystor:nsstring); r=mystor
1 new changesets; new tip is 196206f129efbc4331dc8641e90acd2c5f8d36e2
pushing 1 new changesets on head 196206f129efbc4331dc8641e90acd2c5f8d36e2 to ssh://hg.mozilla.org/integration/autoland
387414:196206f129ef: servo: Merge #18941 - Move nsstring from gecko into servo/support/gecko/nsstring (from mystor:nsstring); r=mystor
executing: hg push -r 196206f129efbc4331dc8641e90acd2c5f8d36e2 ssh://hg.mozilla.org/integration/autoland
hg> pushing to ssh://hg.mozilla.org/integration/autoland
hg> remote:
hg>   https://hg.mozilla.org/integration/autoland/rev/196206f129efbc4331dc8641e90acd2c5f8d36e2
Using /home/servo-sync/.cargo/bin/cargo-vendor
rm -rf /home/servo-sync/firefox-overlay/third_party/rust
Adding nsstring v0.1.0 (file:///home/servo-sync/firefox-overlay/xpcom/rust/nsstring)
Adding nsstring v0.1.0 (file:///home/servo-sync/firefox-overlay/xpcom/rust/nsstring)
error: failed to sync
Caused by:
failed to load pkg lockfile
Caused by:
failed to parse lock file at: /home/servo-sync/firefox-overlay/toolkit/library/rust/Cargo.lock

2017-10-20T19:06:33
rm -rf /home/servo-sync/firefox-overlay/third_party/rust
error: failed to load source for a dependency on `nsstring-gtest`
Caused by:
Unable to update file:///home/servo-sync/firefox-overlay/xpcom/rust/gtest/nsstring
Caused by:
failed to read `/home/servo-sync/firefox-overlay/xpcom/rust/gtest/nsstring/Cargo.toml`
Caused by:
No such file or directory (os error 2)

2017-10-21T10:09:24
hg> pulling https://hg.mozilla.org/projects/converted-servo-linear into /home/servo-sync/firefox-overlay/.hg/hg.mozilla.org__projects__converted-servo-linear
hg> searching for changes
hg> adding changesets
hg> adding manifests
hg> adding file changes
hg> added 1 changesets with 19 changes to 19 files
hg> 5ff779ed758c already processed as 487c7f620b0c; skipping 10405/10406 revisions
hg> abort: metadata mismatch for file servo/components/style/gecko_bindings/nsstring_vendor/src/lib.rs between source and dest: {'copy': 'support/gecko/nsstring/src/lib.rs'} != None
abort: hg command failed
timeline:

the servo side of https://bugzilla.mozilla.org/show_bug.cgi?id=1403213 lands via https://github.com/servo/servo/pull/18941

this caused the parse lock failure, and was backed out of autoland
https://hg.mozilla.org/integration/autoland/rev/becff95c9e4c
https://hg.mozilla.org/integration/autoland/rev/69998f1363be

due to bug 1410323, servo-backout-pr updated a closed PR
https://github.com/servo/servo/pull/18577#issuecomment-338043015

so a backout pr is manually created
https://github.com/servo/servo/pull/18975


i was made aware of this after all this had happened, and at the time things looked sane (eg. the first error email i received was more than 12 hours after).

what i'd forgotten about was that servo-vcs-sync skip overlaying revisions that were authored by our servo-backout-pr author.  emilio's manually authored backout was not skipped.
what's interesting here is it didn't immediately fail; it failed 6 revisions after the manual backout.
i've been able to reproduce this locally, which has shed some light on what's going on.

it appears to be related to this merge: https://hg.mozilla.org/integration/autoland/rev/4588832bab79 which happened after the last successful servo merge.

prior to this merge, the metadata for servo/components/style/gecko_bindings/nsstring_vendor/src/lib.rs had it tagged as a copy:

> \1
> copy: support/gecko/nsstring/src/lib.rs
> copyrev: 78b62d691d5660cd77f9d30e3a1a2c40b8d7e2c8
> \1
> /* This Source Code Form is subject to the terms of the Mozilla Public
> ..

4588832bab79 changed it, stripping the copy metadata:

> /* This Source Code Form is subject to the terms of the Mozilla Public
> ..
because servo-vcs-sync is checking against tip, we should be able to fix this by pushing some dummy operations to put the copy meta back:

here's something that worked locally:

> mkdir -p $( dirname servo/support/gecko/nsstring/src/lib.rs )
> touch servo/support/gecko/nsstring/src/lib.rs
> hg add servo/support/gecko/nsstring/src/lib.rs
> hg commit -m 'dummy file to set up a fixup commit'
> hg cp --after --force servo/support/gecko/nsstring/src/lib.rs servo/components/style/gecko_bindings/nsstring_vendor/src/lib.rs
> hg commit -m 'fixup commit to restore copy metadata'
> hg rm servo/support/gecko/nsstring/src/lib.rs
> hg commit -m 'remove dummy file'
gps, i'd like a sanity check from you on my proposed fix in comment 4.

i'll continue looking to see if there's a way to do this in a single commit.
Flags: needinfo?(gps)
We /could/ manually craft a manifest to avoid 2 commits. But the solution outlined in comment #4 WFM.
Flags: needinfo?(gps)
Pushed by gszorc@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a94100b29cfc
Dummy file to help restore Servo VCS syncing; r=me
https://hg.mozilla.org/integration/autoland/rev/388902bd2dd5
Restore copy metadata for Servo file; r=me
https://hg.mozilla.org/integration/autoland/rev/9be5742835ec
Remove dummy file to fix Servo sync state; r=me
I landed the dummy commits to restore the metadata. I manually ran the overlay service and it resulted in https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=03a03dbbfcdd.

The real-time syncing should be restored shortly.
Assignee: nobody → gps
Status: NEW → ASSIGNED
All services up and running. It is currently working through a backlog.

Ran into some issues with cargo vendoring bustage related to nsstring and an incomplete patch in bug 1403213. But vendoring ran once. So I think we're OK.
all looks good; closing.
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.