Qt WebKit removed from upstream on 10/02/2013
- Latest QtWebKit trunk revision is r156769
- Branch for Qt 5.2: https://gitorious.org/qtwebkit/qt5x2/
- Trunk must build on all of our platform
- Don't bring regressions into the tree
- Buildbots should be green almost at all times
First steps before gardening
- Get Ubuntu 12.04 or 12.10 and install it. Install this metapackage: https://launchpad.net/~u-szeged/+archive/sedkit
* sudo apt-get install python-software-properties * sudo add-apt-repository ppa:u-szeged/sedkit * sudo apt-get update * sudo apt-get install sedkit-env-qtwebkit
- Install GStreamer 1.0 (Will be mandatory soon, see https://bugs.webkit.org/show_bug.cgi?id=106669 for details)
* sudo add-apt-repository ppa:gstreamer-developers/ppa * sudo apt-get update * sudo apt-get install gstreamer1.0 libgstreamer-plugins-base1.0-dev
- Decrease the stack size if you work on x86 (32 bit) - See https://bugs.webkit.org/show_bug.cgi?id=88966#c8 for details
* Add this line to /etc/security/limits.conf: "* hard stack 1024" * It is necessary for fast/workers/wrapper-map-gc.html, fast/js/create-lots-of-workers.html and fast/workers/dedicated-worker-lifecycle.html
- Build the actual Qt 5 for the WebKit trunk with this builder script:
* git clone git://github.com/ossy-szeged/qt5-tools.git * ./build-qt5.sh * If there is Qt5 update, then the only thing left is to use git pull and run the script again. note: * build-qt5.sh uses 30 threads by default (-j option) * Qt is installed into /usr/local/Trolltech (normal user doesn't have write permission for it by default
- Download testfonts, set environment variables (note: the latest suffix of QTDIR is QT_WEEKLY_REV in build-qt5-env)
* git clone git://gitorious.org/qtwebkit/testfonts.git * export WEBKIT_TESTFONTS=/home/webkit/testfonts * export TZ=America/Los_Angeles ( to make all JSC tests pass :) ) * export QTDIR=/usr/local/Trolltech/Qt5/Qt-5.1.1 * export PATH=/usr/local/Trolltech/Qt5/Qt-5.1.1/bin:$PATH
- Download WebKit, configure git svn, build WebKit.
* git clone git://git.webkit.org/WebKit.git WebKit * cd WebKit * git svn init --prefix=origin/ -T trunk http://svn.webkit.org/repository/webkit * git config --replace svn-remote.svn.fetch trunk:refs/remotes/origin/master * git svn fetch * to build: Tools/Scripts/build-webkit (Set MAKEFLAGS=-j5)
- You are ready for Gardening. ;)
How to gardening
- Starting point is the waterfall: ( http://build.webkit.sed.hu/waterfall, http://build.webkit.org/waterfall )
- If You can see red bots...
- Determine which changeset caused the fail
- Waterfall is your friend ;)
- TestFailures tool is your friend too
- Show more tests on waterfall: Click on a builder and then ( Show: default 25 50 100 200 )
- Click on "Build #", you can see the blamelist
- If the blamelist is too big, check more builders
- If the blamelist is still too big, use git bisect locally to find the culprit
- If it is a simple buildfix, or Qt specific rebaseline, do it yourself immediately.
- If the bug is platform independent (fail on Apple, GTK or EFL too) and bigger than a simple fix,
try to ping the author and the reviewer and/or comment the original bug. If they don't answer in 15-20 minutes:
- rollout with webkitbot:
- On #webkit: webkitbot: rollout 12345 It broke the build on SL, GTK, Qt
- Land the rollout patch manually or mark it with cq+ to land it by commit queue.
- or file a new bug report about the regression and put the failing tests to the Skipped list (qt, qt-5.0-wk1 or qt-5.0-wk2) See: Create new bug report
- rollout with webkitbot:
- You should check whether the test fails on wk1, wk2 or both.
- You should check if it's a 32-bit or a 64-bit bug (or it happens on both systems) - JSC patches sometime break only 32 or 64 bit platforms
- You should check if it's a release or a debug bug (or it happens on both systems) - ASSERTS are checked in debug mode only
Tips and tricks
- Use cc input field completion tool on BugZilla to find a nickname from e-mail address or real name (It works only with WebKit based browsers!)
- Use "old-run-webkit-tests --platform mac -p name-of-the-failing test" to determine if the tests needs only rebaseline or not (If you are sure if the Mac result is correct.)
- Use "webkit-patch rebaseline" if you are sure if the actual result is correct on the bot (for text only tests!)
- Use "old-run-webkit-tests --platform qt -p --reset-results --add-platform-exception name-of-the-failing test" to create new results
Create new bug report
- There's no need to create a bug report:
- If there is already a related bug report about the test or about problems covering the tests (for example: unimplemented features)
- In any other case, it is recommended to create a bug report, in which you inform the author and the reviewer about the current error. The developer can inform you whether this result is the (new) expected result (rebaseline) or it is an error indeed (Skip).
- Create bug report step by step:
- Enter a new bug report
- Component: Tools / Test
- CC fields: You should send this report to the author of the patch, the reviewer, or perhaps some other gardeners. Use cc input field completion tool on BugZilla to find a nickname by e-mail address or real name (It only works with WebKit based browsers!)
- Summary: A short description about the fail. For example:
[Qt] REGRESSION (r53450): fast/forms/textarea-scrollbar-height.html fails. [Qt][WK2] fast/forms/range/slider-mouse-events.html and fast/forms/range/slider-onchange-event.html fail after r124625. [Qt] new test editing/spelling/spelling-unified-emulation.html is failing.
- Description: Detailed description of the fail by giving the test results! (Diff).
- Blocks: You should add to the blocks list the correct meta bug number AND the original bug:
* newly added failing test: 87008 * REGRESSION: 79666 * crash/timeout: 79668 * API-WK1: 38654 * API-WK2: 70236
- For example for rebaseline:
- Changes caused by testfonts update.
- Modify test results. Should update test expectation.
You can easily decide if a test only needs rebaseline. You can compare the result with results on other platforms.
- "run-webkit-tests --qt --compare-port port name-of-the-failing test"
- "webkit-patch rebaseline" if you are sure if the actual result on the bot is correct (for text only tests!)
- "webkit-patch garden-o-matic"
- [WK1]"Tools/Scripts/run-webkit-tests --qt --new-baseline --additional-platform-directory= "platform absolute name" -p --test-list= List" Text + PNG
- [WK2]"Tools/Scripts/run-webkit-tests --qt -2 --new-baseline --additional-platform-directory=/home/kadam/webkit/WebkitGardener/LayoutTests/platform/qt -p --test-list= List" Text + PNG
- First of all, the most important thing: don't skip thoughtlessly!
- If the bug is Qt specific and you can't fix it immediately, file a bug [Create bug report] about it, and put the failing tests to the Skipped list.
- The Skipped list has a regular structure. Try to put the test into the appropriate group. For example: Failing fast tests, Failing editing/selection tests etc.
- When skipping a test, put it on the appropriate skipped list. You should clarify if it's just Qt, or WebKit1 or WebKit2 specific, and use the Skipped lit accordingly.
- For example:
- If the test is Qt specific and fails on both (WK1 and WK2) bots, then use LayoutTests/platform/qt/Skipped.
- If the test is Qt specific and fails only on WK1 or WK2, then use LayoutTests/platform/qt-5.0-wk1/Skipped or LayoutTests/platform/qt-5.0-wk2/Skipped.
- If it fails also on other platforms and the problem occurs only on WebKit2, then you should use LayoutTests/platform/wk2.
- Bug report has to be filled accordingly and You should write it the original bug.
- Principle: If anybody write comment to the bug report later, then try to fix the bug about this suggestion or find anybody else to fix it. (We can't expect if an Apple, Google, ... developer fix Qt related bugs, but usually they can give us useful advices how can we fix the bug.
- Some examples for skipping:
# [Qt] REGRESSION(r113520): fast/transforms/scrollIntoView-transformed.html fails # https://bugs.webkit.org/show_bug.cgi?id=83419 fast/transforms/scrollIntoView-transformed.html
# [Qt] New fast/forms/number/number-validation-message.html introduced in r121019 fails. # https://bugs.webkit.org/show_bug.cgi?id=89760 fast/forms/number/number-validation-message.html
- You need to pay attention to disabled and unimplemented features.
- Missing things on the Skipped list can be found at "Missing features in our DumpRenderTree implementation" and "Disabled features" sections.
- Some for example:
- ENABLE(SHADOW_DOM) is disabled.
- ENABLE(MUTATION_OBSERVERS) is disabled.
- Drag and Drop Support in DRT:
- DumpRenderTree needs eventSender.beginDragWithFiles() implementation
- Qt Linux Release minimal bot is to test if every feature is correctly guarded by #ifdef-s.
- Examples for --minimal buildfix:
- You can run tests with the following commands:
Help the others to fix Qt related build issues:
- Patches did not build on the Qt WK1 EWS in the last 7 days
- Patches did not build on the Qt WK2 EWS in the last 7 days
(FIXME: These searches aren't perfect, because they don't know if the build failure is still valid. They simple
search bugs modified in the last 7 days and with "did not pass on qt-ews/qt-wk2-ews" comment sometime in the past.)
- rebaseline_example.jpg (62.3 KB) - added by 5 years ago.
- rebaseline_example2.jpg (61.1 KB) - added by 5 years ago.
- Mutation_example.jpg (86.5 KB) - added by 5 years ago.
- draganddrop_example.jpg (22.9 KB) - added by 5 years ago.
- Shadowproblem_example.jpg (12.2 KB) - added by 5 years ago.
Download all attachments as: .zip