[webkit-dev] running webkit in unbuntu
Hi, Af ter executing ./build-webkit in ubuntu 9.1 linux I agetting following error: upported platform, can't determine built library locations. at /home/test/Webkit/Webkit/WebKitTools/Scripts/webkitdirs.pm line 577. Same errot comes for run-safari, run-laauncher etc.. present in ithe webkittools/scripts folder . Can anybody suggest the solution for the same? Regards Shiv The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Embedded Software India Pvt. Ltd. (TESI),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] running webkit in unbuntu
You should pick which Linux-based WebKit to build, and then follow their build instructions. http://trac.webkit.org/wiki/BuildingGtk https://trac.webkit.org/wiki/BuildingQtOnLinux (Note also that Safari is only available for MacOS and Windows.) On Thu, Mar 18, 2010 at 8:07 AM, Shivaprasad P shivaprasad.ang...@toshiba-tesi.com wrote: Hi, Af ter executing ./build-webkit in ubuntu 9.1 linux I agetting following error: upported platform, can't determine built library locations. at /home/test/Webkit/Webkit/WebKitTools/Scripts/webkitdirs.pm line 577. Same errot comes for run-safari, run-laauncher etc.. present in ithe webkittools/scripts folder . Can anybody suggest the solution for the same? Regards Shiv The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Embedded Software India Pvt. Ltd. (TESI),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web developer documentation - working with Mozilla
On Mar 18, 2010, at 12:20 AM, ext Maciej Stachowiak wrote: On Mar 17, 2010, at 8:55 AM, henry.haveri...@nokia.com wrote: I'm working for the Qt port of WebKit, and we're currently considering different ways of creating web developer documentation for our users. We don't currently have any documentation for web developers We'd like to start with best practice articles and tutorials for some HTML5 and CSS3 features but later extend to the basics and general reference guides too. We have a rough start on some developer documentation on webkit.org: http://trac.webkit.org/wiki/WebDevelopers That's nice to have. Ideally, we should have a neutral, vendor independent place for working on WebKit documentation, for example at the webkit.org wiki. A problem with the current wiki is that we don't have a clear license for the content and the modifications that the contributors make , so it's not clear if we could redistribute the documentation for example with our SDK. Should we have a fresh start with a new section in the wiki that has an explicit license policy? Maybe we should use the same license as Mozilla to make it easy to share stuff. We could also autogenerate a documentation skeleton from the lists of elements, attributes, and DOM interfaces that are actually found in the source code. There is a mostly autogenerated DOM reference on developer.apple.com: http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/WebKitDOMRef/index.html Also documentation of CSS rules: http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariCSSRef/Introduction.html We could easily autogenerate something similar for webkit.org if we cared to. That'd be excellent! Are the tools that you use for autogenerating the Apple documentation openly available? I'd personally rather not send people looking for WebKit Web developer documentation to mozilla.org. Cross-browser documentation is useful, but WebKit-specific documentation is useful too. I agree we need WebKit specific documentation, and sometimes we need to be specific about the port of WebKit too, at least when documenting for example the QtWebKit version where a certain feature was first supported. I wouldn't mind working on the Mozilla site -- they seem to be open towards having WebKit specific docs there -- but I would be happy to work on a webkit specific resource too. Regards, Henry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web developer documentation - working with Mozilla
On Mar 17, 2010, at 10:06 PM, ext Peter Kasting wrote: On Wed, Mar 17, 2010 at 8:55 AM, henry.haveri...@nokia.com wrote: We don't currently have any documentation for web developers We'd like to start with best practice articles and tutorials for some HTML5 and CSS3 features but later extend to the basics and general reference guides too. This sounds like the mission of http://code.google.com/doctype/ , though I don't know how well that site achieves it. I suspect the maintainers would be happy for more content. Thanks for the pointer! I need to look into this. I like the fact that the compatibility tables are based on real test cases. Regards, Henry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] git fetch failing, possible repository corruption
This morning, whenever I try to pull from webkit's git repo I get the following scary error: remote: error: failed to unpack compressed delta at offset 167772124 from ./objects/pack/pack-48166dba7808af6c8cbc7b74dada2c456e2ba411.pack remote: error: failed to read object be61563cc282b7c036d656ec05df6d5d66be4be7 at offset 167772121 from ./ objects/pack/pack-48166dba7808af6c8cbc7b74dada2c456e2ba411.pack remote: fatal: object be61563cc282b7c036d656ec05df6d5d66be4be7 is corrupted remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header The only recent post about git I've seen is git.webkit.org is missing svn revision r49890, which doesn't seem related. (Looking at the output closely, I'm now wondering if the double appearance of 'remote' (remote: aborting due to possible repository corruption on the remote side) means the warning is about my _local_ repo?) —Jens ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git fetch failing, possible repository corruption
See this: https://bugs.webkit.org/show_bug.cgi?id=36193 On Thu, Mar 18, 2010 at 1:25 PM, Jens Alfke s...@chromium.org wrote: This morning, whenever I try to pull from webkit's git repo I get the following scary error: remote: error: failed to unpack compressed delta at offset 167772124 from ./objects/pack/pack-48166dba7808af6c8cbc7b74dada2c456e2ba411.pack remote: error: failed to read object be61563cc282b7c036d656ec05df6d5d66be4be7 at offset 167772121 from ./objects/pack/pack-48166dba7808af6c8cbc7b74dada2c456e2ba411.pack remote: fatal: object be61563cc282b7c036d656ec05df6d5d66be4be7 is corrupted remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header The only recent post about git I've seen is git.webkit.org is missing svn revision r49890, which doesn't seem related. (Looking at the output closely, I'm now wondering if the double appearance of 'remote' (remote: aborting due to possible repository corruption on the remote side) means the warning is about my _local_ repo?) —Jens ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git fetch failing, possible repository corruption
On Mar 18, 2010, at 10:29 AM, tonikitoo (Antonio Gomes) wrote: See this: https://bugs.webkit.org/show_bug.cgi?id=36193 I already mentioned I'd looked at that; but evidently I hadn't read carefully through to comment #12, which describes the exact issue I reported. Thanks. —Jens___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web developer documentation - working with Mozilla
On Mar 18, 2010, at 9:03 AM, henry.haveri...@nokia.com wrote: On Mar 17, 2010, at 10:06 PM, ext Peter Kasting wrote: On Wed, Mar 17, 2010 at 8:55 AM, henry.haveri...@nokia.com wrote: We don't currently have any documentation for web developers We'd like to start with best practice articles and tutorials for some HTML5 and CSS3 features but later extend to the basics and general reference guides too. This sounds like the mission of http://code.google.com/doctype/ , though I don't know how well that site achieves it. I suspect the maintainers would be happy for more content. Thanks for the pointer! I need to look into this. I like the fact that the compatibility tables are based on real test cases. The documentation on Google doctype has quite a few errors and doesn't seem to have been updated for a while. For example, this test claims that Safari 3 does not apply style for the a element which is clearly wrong: http://code.google.com/p/doctype/wiki/AElement Many of the HTML element documentation pages have similar errors. I reported some of these errors nearly two years ago and many still persist. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web developer documentation - working with Mozilla
On Thu, Mar 18, 2010 at 10:38 AM, Maciej Stachowiak m...@apple.com wrote: The documentation on Google doctype has quite a few errors and doesn't seem to have been updated for a while. For example, this test claims that Safari 3 does not apply style for the a element which is clearly wrong: http://code.google.com/p/doctype/wiki/AElement Many of the HTML element documentation pages have similar errors. I reported some of these errors nearly two years ago and many still persist. I don't have any connection to doctype, but it's a wiki, so it's possible to simply edit and correct pages directly, isn't it? PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web developer documentation - working with Mozilla
On Mar 18, 2010, at 11:07 AM, Peter Kasting wrote: On Thu, Mar 18, 2010 at 10:38 AM, Maciej Stachowiak m...@apple.com wrote: The documentation on Google doctype has quite a few errors and doesn't seem to have been updated for a while. For example, this test claims that Safari 3 does not apply style for the a element which is clearly wrong: http://code.google.com/p/doctype/wiki/AElement Many of the HTML element documentation pages have similar errors. I reported some of these errors nearly two years ago and many still persist. I don't have any connection to doctype, but it's a wiki, so it's possible to simply edit and correct pages directly, isn't it? I filed issues on some of the problems I found in the issue tracker, nearly two years ago. While it is possible to edit wiki pages, I believe many of these pages are autogenerated in part or in whole, so I'm not sure if it is safe to hand-edit. Also much of the incorrect information is based on buggy tests that are kept in a version control system, not in the wiki. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web developer documentation - working with Mozilla
Rather than guess at answers to your comments, I CCed Mark Pilgrim, the doctype owner, who will know what to do with this info. PK On Thu, Mar 18, 2010 at 11:18 AM, Maciej Stachowiak m...@apple.com wrote: On Mar 18, 2010, at 11:07 AM, Peter Kasting wrote: On Thu, Mar 18, 2010 at 10:38 AM, Maciej Stachowiak m...@apple.com wrote: The documentation on Google doctype has quite a few errors and doesn't seem to have been updated for a while. For example, this test claims that Safari 3 does not apply style for the a element which is clearly wrong: http://code.google.com/p/doctype/wiki/AElement Many of the HTML element documentation pages have similar errors. I reported some of these errors nearly two years ago and many still persist. I don't have any connection to doctype, but it's a wiki, so it's possible to simply edit and correct pages directly, isn't it? I filed issues on some of the problems I found in the issue tracker, nearly two years ago. While it is possible to edit wiki pages, I believe many of these pages are autogenerated in part or in whole, so I'm not sure if it is safe to hand-edit. Also much of the incorrect information is based on buggy tests that are kept in a version control system, not in the wiki. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Running pixel tests on build.webkit.org
The thing I find most difficult about not having pixel bots is that, if I make a change that changes pixel results, I need to actually build that change on every platform to get the new pixel results. Could we put up pixel bots on a separate waterfall? It's a waterfall we don't expect to keep green all the time. This has a few advantages over the current state of the world: 1. When making cross-platform changes, it's easy to grab pixel results off the bots. 2. When making changes that affect pixel tests, it's easier to see which pixel failures are regressions caused by my patch. I think these two would greatly help in stemming the tide of pixel test regressions. Does that seem possible/reasonable? Ojan On Mon, Jan 11, 2010 at 9:17 AM, Jeremy Orlow jor...@chromium.org wrote: Wow, much easier than I expected. :-) OK, then what about buy in on this approach? I'll even file bugs on everything I rebaseline so we can track getting things back to a correct state and/or verifying that the new baselines are correct. J On Mon, Jan 11, 2010 at 9:13 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: It's baiscally just run-webkit-tests --reset-results --pixel-tests. No magic :) See run-webkit-tests --help for more info. BTW, Victor is working to port the rebaselining tool to build.webkit.org. You may want to check with him -- maybe he's close to finishing the patch. :DG On Mon, Jan 11, 2010 at 9:06 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Jan 8, 2010 at 9:52 AM, Jeremy Orlow jor...@chromium.org wrote: Plan 3 seems like the best (and simplest) one until the infrastructure for the others (and/or a champion for fixing currently failing tests) is available. What would it take to go with plan 3? I guess someone needs to rebaseline everything that's currently failing, check them in, and then someone (like bdash?) needs to flip a switch on the bots...? Did I miss anything? Are there instructions on how to do the rebaselining anywhere? I've only ever created pixel baselines for Chromium before (where we have a pretty neat tool that pretty much does it for you). Does anyone know? I'm happy to do the rebaselining if someone can tell me how and we agree to turn pixel tests on on the bots. On Fri, Jan 8, 2010 at 9:23 AM, Pam Greene p...@chromium.org wrote: And one very quick, short-term solution: 3. Generate new pixel results to match the current behavior, and check them in as hypothetically correct. And of course if someone notices an existing problem and fixes it, they check in corrected images then. It doesn't help find current problems, but those are being missed now anyway. It does let the tests be run again approximately immediately, even faster than waiting for test expectations functionality, so we can catch regressions moving forward. - Pam On Thu, Jan 7, 2010 at 5:01 PM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 7, 2010 at 10:22 AM, Darin Adler da...@apple.com wrote: On Jan 7, 2010, at 10:19 AM, Dimitri Glazkov wrote: Are we planning to run pixel tests on the build bots? If we can get them green, we should. It’s a lot of work. We need a volunteer to do that work. We’ve tried before. Two possible long-term solutions come to mind: 1. Turn the bots orange on pixel failures. They still need fixing, but are not as severe as text diff failures. I'm not a huge fan of this, but it's an option. 2. Add in a concept of expected failures and only turn the bots red for *unexpected* failurs. More details on this below. In chromium-land, there's an expectations file that lists expected failures and allows for distinguishing different types of failures (e.g. IMAGE vs. TEXT). It's like Skipped lists, but doesn't necessarily skip the test. Fixing the expected failures still needs doing of course, but can be done asynchronously. The primary advantage of this approach is that we can turn on pixel tests, keep the bots green and avoid further regressions. Would something like that make sense for WebKit as a whole? To be clear, we would be nearly as loathe to add tests to this file as we are about adding them to the Skipped lists. This just provides a way forward. While it's true that the bots used to be red more frequently with pixel tests turned on, for the most part, there weren't significant pixel regressions. Now, if you run the pixel tests on a clean build, there are a number of failures and a very large number of hash-mismatches that are within the failure tolerance level. -Ojan For reference, the format of the expectations file is something like this: // Fails the image diff but not the text diff. fast/forms/foo.html = IMAGE // Fails just the text diff. fast/forms/bar.html = TEXT // Fails both the image and text diffs. fast/forms/baz.html = IMAGE+TEXT // Skips this test (e.g. because it hangs run-webkit-tests or causes
