|
|
| Line 1: |
Line 1: |
| | |
| | <big><span style="color: red">Note: If you are trying to do a fast-forward update please go</span> [[Media/WebRTC/libwebrtc_Update_Process|here]]. |
| | </big><br /> |
| | <big><span style="color: red">Note: If you are trying to do a fast-forward update please go</span> [[Media/WebRTC/libwebrtc_Update_Process|here]]. |
| | </big><br /> |
| | <big><span style="color: red">Note: If you are trying to do a fast-forward update please go</span> [[Media/WebRTC/libwebrtc_Update_Process|here]]. |
| | </big> |
| | |
| This describes the rough plan to document and automate the process to "fast-forward" through webrtc.org libwebrtc change-sets to bring Firefox's libwebrtc version as close as possible to Chrome. This page will be updated as new information is discovered. | | This describes the rough plan to document and automate the process to "fast-forward" through webrtc.org libwebrtc change-sets to bring Firefox's libwebrtc version as close as possible to Chrome. This page will be updated as new information is discovered. |
|
| |
|
| Line 224: |
Line 232: |
| requiring lots of network. | | requiring lots of network. |
| * Do we want to add our fixup-patch to the moz-libwebrtc branch and move the branch forward in the official repo to make it more clear what was previously vendored? | | * Do we want to add our fixup-patch to the moz-libwebrtc branch and move the branch forward in the official repo to make it more clear what was previously vendored? |
|
| |
| == Operation Checklist ==
| |
| === Prerequisites ===
| |
| - Create a new bug for the fast-forward update. It should depend on the previous fast-forward bug. [https://bugzilla.mozilla.org/show_bug.cgi?id=1800920 Bug 1800920] is an example.
| |
|
| |
| - Builds are done after vendoring in each commit. Having a <code>.mozconfig</code> file that enables cache (either sccache or ccache) will improve the performance of the scripts.
| |
| hg clone https://hg.mozilla.org/projects/elm
| |
| (cd elm && ./mach bootstrap --application-choice=browser && ./mach build)
| |
| git clone https://github.com/mozilla/libwebrtc moz-libwebrtc
| |
|
| |
| === Update steps ===
| |
| # Start from the elm checkout
| |
| cd elm
| |
|
| |
| # Prepare the github repo
| |
| bash dom/media/webrtc/third_party_build/prep_repo.sh
| |
|
| |
| # Run loop-ff.sh
| |
| bash dom/media/webrtc/third_party_build/loop-ff.sh
| |
|
| |
| === Operational notes ===
| |
| - Running <code>prep-repo.sh</code> with a fresh github clone of moz-libwebrtc will likely display instructions on how to add recent moz-central changes made in <code>third_party/libwebrtc</code> to the top of the patch stack in github. This is expected and necessary for successfully vendoring changes into <code>third_party/libwebrtc</code>.
| |
|
| |
| - Two main types of errors will cause <code>loop-ff.sh</code> to exit; the first is a rebase conflict, the second is a build error due to api changes in upstream code.
| |
|
| |
| - When making changes to fix build issues in moz-libwebrtc, mercurial commit messages follow the pattern:
| |
| Bug xxx - (fix-{upstream-sha}) {description}
| |
|
| |
| - When making changes to fix Mozilla code in response to changes upstream, mercurial commit messages follow the pattern:
| |
| Bug xxx (MOZ) - {description}
| |
|
| |
| - While loop-ff.sh is running, in a separate terminal window it may be helpful to see the overall progress by running:
| |
| tail -f ~/log-loop-ff.txt | grep loop-ff
| |
|
| |
|
| == Moving third_party/libwebrtc/third_party/* to third_party/* == | | == Moving third_party/libwebrtc/third_party/* to third_party/* == |
| Line 317: |
Line 292: |
| #* https://manpages.debian.org/testing/pax-utils/scanelf.1.en.html | | #* https://manpages.debian.org/testing/pax-utils/scanelf.1.en.html |
| #* https://stackoverflow.com/questions/50303305/elf-file-type-et-exec-and-et-dyn | | #* https://stackoverflow.com/questions/50303305/elf-file-type-et-exec-and-et-dyn |
|
| |
| = Resetting Elm =
| |
| Before each new merge cycle. Elm needs to be reset to Central, and the floating patches need to be reapplied.
| |
| # Ensure you have filed a bug for the next merge cycle, and further ensure that the next merge cycle bug has the previous merge cycle bug as a dependency.
| |
| # Make sure you have a local checkout of Elm which includes the floating patches.
| |
| # File a bug as a clone of [https://bugzilla.mozilla.org/show_bug.cgi?id=1789675 Bug 1789675] and add your new bug as dependency to the next merge cycle bug.
| |
| # Wait for the repo admins to reset the repository.
| |
| # Mark the floating arc config patch with a bookmark. If the patch had id `5e8481a558fb` then one would run <syntaxhighlight lang="Bash">hg bookmark -r 5e8481a558fb ARC_CONFIG_FLOAT</syntaxhighlight>
| |
| # Pull the new head of Elm. <syntaxhighlight lang="Bash">hg pull</syntaxhighlight>.
| |
| # Rebase the floating patches onto the new checkout of Elm, then checkout the new tip. <syntaxhighlight lang="Bash">
| |
| hg rebase --keep -s ARC_CONFIG_FLOAT -d elm && \
| |
| hg co tip && \
| |
| hg bookmark ARC_CONFIG_FLOAT
| |
| </syntaxhighlight>
| |
| # Push the floating patches to Elm. <syntaxhighlight lang="Bash">hg push --bookmark=ARC_CONFIG_FLOAT</syntaxhighlight>
| |
| # Celebrate
| |