Re: [Development] Copyright changes
On Sat, Mar 2, 2013 at 3:34 PM, Laszlo Papp lp...@kde.org wrote: I will take you meant QT_MODULE_TO_TEST=qtdeclarative qtqa/tests/prebuild/license/tst_licenses.pl Yeah, I used this script earlier, but I did not know it is already integrated into the CI. Couldn't this be integrated into a bot rather than CI? It would be nice to know even before pressing the staging button. It does not seem to run long either. Sure, there is a long standing task for that, https://bugreports.qt-project.org/browse/QTQAINFRA-309 . It just waits for somebody to do the work. The current sanity bot has all checks implemented in a couple of big loops and is not designed to call out to separate scripts, so this task may include some refactoring of the sanity bot. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] On the reliability of CI
Shawn Rutledge said: On Thu, Oct 25, 2012 at 01:00:47PM +1000, Rohan McGovern wrote: Replying here to some comments on IRC, since I'm rarely online at the same time as the others, but I don't want to let all the comments go unanswered... steveire [06:32:44] CI is seriously depresssing. For the last 24 hours there has been one successful merge. Many of the others are failing because of something in network. Personally I think the fundamental problem which CI could do better is to triage problems. Often patches get staged in large batches, so when the whole batch fails it's very easy to take a quick look at the failure, think that can't possibly be because of what I did, and leave it to someone else who presumably understands his own code better. But maybe that person also takes a while to realize that his code was really the cause. I think when a test fails, the CI system should try to break down the patch set in some way. For example it could divide the patch set in half, arbitrarily, and see if half of them will integrate successfully, then the other half, and continue this recursively until the one bad patch is found, or at least a smaller subset. I think there are two major flaws in need of attention. One of them is the batching of changes as you say; that's clearly the least scalable part of the system right now. The other is the fact that the results are not accurate enough (primarily due to flaky tests). The two problems are related; the presence of flaky tests effectively poisons any kind of advanced test strategy, like the bisection you mentioned. Sometimes it's already a challenge to get one test run with accurate results; a bisection process needs a whole string of accurate results, so I think it's unlikely to give a satisfactory outcome without improving the test stability somehow. That's also why I am resistant to some features commonly suggested to save test time at the cost of accuracy, such as incremental builds and applying heuristics to decide what to build/test. I also wonder if one might spend a lot of time implementing a complex post-test bisection process, then find it is easily outperformed by a single human who reads the failure message and the one-line summary of each change and makes a judgment call about what to re-stage... of course, human time is worth a lot more than computer time. Personally I think the logical next step, which could be implemented in parallel to the current setup without drastic new hardware purchases, would be to provide a service where changes in gerrit can be submitted for testing separately from the please merge to stable branch mechanism. Right now, if you know your change is risky, you have best intentions and you would like it tested separately, you have no mechanism for doing that. If that system worked well, it seems to me that naturally the de-facto situation would arise that you should not merge your change to staging unless it has already passed in this system or you have a good reason for doing so. Then it could be considered to make the system semi-mandatory or attempt to build something more complex on top of it (such as described in Charley's mail). Extending the Early Warning System (sanity bot and other similar bots) to also include compile and autotesting might help, but I have a feeling that system could never be extended to cover as many configurations as the full CI, which is likely to always have some un-sandboxable or un-virtualizable platforms. At previous jobs I've seen various more or less unpleasant social regimes to prevent breaking the build, but didn't like any of those, and they are not amenable to distributed projects anyway. For example, the build master does a build every day, or every Friday, and personally nags people if it fails (that was mid-90's, before continuous integration). Later with CI, maybe you have to pay a fine when you break the build; you have to wear a rubber chicken around your neck for a day; or maybe the rubber chicken is used as a token, you can only integrate a set of patches if you possess the chicken, you must control which set of patches are in the batch (ensure you understand them, or at least understand that they are definitely independent), and you cannot pass on the chicken to someone else until all the tests pass. Probably most commercial development is done under some such brute-force regime. But this is a technical problem, seems like it should have a technical solution. I can only imagine for example that Google has a better system for internal development, I just don't know what it is. Trolltech also had a history of some approaches like that. All well intentioned, but I think they were relatively ineffective compared to not letting changes in until after they've passed testing. ___ Development mailing list Development@qt-project.org http://lists.qt
[Development] On the reliability of CI
Replying here to some comments on IRC, since I'm rarely online at the same time as the others, but I don't want to let all the comments go unanswered... steveire [06:32:44] CI is seriously depresssing. For the last 24 hours there has been one successful merge. Many of the others are failing because of something in network. richmoore1 [06:40:03] steveire: a lot of this seems to be caused by the moving of the CI infrstructure to digia. it doesn't seem to be working fully yet I don't think that's true. As far as I know, the projects migrated to Digia have been working fine, and only the Nokia system (which has lost the majority of its support staff) has been having problems. The Nokia qt-test-server kernel recently started to produce kernel: [14564774.569761] swapper: page allocation failure. order:4, mode:0x4020 after 377 days uptime with few problems. I don't think this is directly related to any Nokia - Digia transition activities, rather an unfortunate coincidence of timing. ThorbjornTux [06:54:20] steveire: there was a discussion not that long ago in here ... I think that the conclusion were that tests that failed without reason was ok to be marked as insignificant (as you suggested). ThorbjornTux [06:54:47] steveire: the problem seems only to be if anybody does it .. steveire [06:55:10] Exactly. There used to be people who did things like that. True, there used to be Nokia employees reading every failure report and chasing up apparently unstable tests, either trying to fix the tests, or acknowledge them via bug reports and marking them insignificant. Those people are gone and the test results are likely to be less stable until they're replaced - either by more people doing the same job, or an automated solution to achieve stable test results from an unstable product. jpnurmi [07:30:23] steveire: np, those tests have been annoying me several times :) steveire [07:31:01] Yes. But why did I get so much pushback on fixing it? Something for qt-project to think about. sahumada [07:31:35] because you are not fixing it .. you are hiding it :) steveire [07:32:23] I'm fixing the problem that nothing has any chance of integrating. With your attitude, insignificant_test and QSKIP would not exist or be needed. I think it's great to have more people actively doing something about failing tests, as long as they take responsibility for their actions. The alternative of, when you see a flaky test, waiting for someone to do something, is not going to work (any more?) It might be good to have some guidelines about the best ways to handle flaky tests, since there are several options. torarne [09:18:47] anyone got powers to put things into qt5.git without the ci getting in the way? There's no built-in mechanism to bypass the system. We haven't needed one so far, we've always managed to handle problems as they arise. If it were an acceptable option to bypass the system when problems occur, it seems to me it would greatly reduce the incentive to fix the problems. steveire [10:34:22] Right. Anyone who can do anything doesn't really care. This is the kind of thing that should be fixable quickly The first part is false. I care, and I can do something - just not at the time you've reported the issue (although I was probably awake, I made a choice a while ago to minimize time spent fixing problems outside of normal working hours, because I felt it was burning me out). Actually, every CI failure which is not related to any of the changes under test slightly erodes my soul. I can guarantee I've been at least as frustrated as any users of the system, during its most unreliable times. The latter part is true and the problem was fixed quickly (for some subjective value of quickly), once it was known. richmoore1 [10:36:01] doing CI from one side of the world to the other is optimistic Yup, we used to have the Pulse server and all clients located together in Brisbane. The migration to Jenkins meant the server was moved to Europe. We have suffered a little bit from that. Luckily, this will soon be over; just a few more days and everything will be operating out of Europe. steveire [10:36:50] And yet, there's been no communication on the mailing list about the network problems (affecting everyone staging anything), despite the fact that it's been known since Monday at least. steveire [10:39:19] The insignification should have been done on Monday imo I didn't understand this part. There has been no known problem since Monday, this seems to be a false assumption. The specific network problem you're complaining about was reported to JIRA by you, last night at 9pm my time, and fixed by me within the first 30 minutes of my working day today. Reporting problems greatly increases the likelihood of a timely fix. You'll be able to get technical support within your own timezone once the transition to Digia completes. Please note that several days of instability doesn't imply
[Development] Nominating Janne Anttila as Approver
I hereby nominate Janne Anttila as an approver. Janne has a long history with Qt, going back (at least?) to the initial Qt for S60 port in 2008. In the past several years, Janne has contributed many fixes to all platforms (especially, it seems, those platforms which nobody else likes to work on :) I count over 500 commits in Qt authored or reviewed by Janne. Recently, Janne has also been leading the creation of Digia's new test farm to be used in the Qt Project CI system. See Janne's dashboard and recently merged patches for further evidence of his many contributions: https://codereview.qt-project.org/#dashboard,1000971 https://codereview.qt-project.org/#q,owner:janne.anttila%2540digia.com+status:merged,n,z ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Issue when setting up the network test server
Sébastien Fricker said:
Hi,
I had a try to follow
http://qt.gitorious.org/qtqa/sysadmin/blobs/master/README.network_test_server.txt
to setup the network test server for the code coverage statistic computation
(http://download.froglogic.com/public/qt5-squishcoco-report/)
I'm facing on an issue:
To reconfigure, run: /var/qtqa/sysadmin/puppet/nodecfg.pl -interactive
+ echo Running puppet...
Running puppet...
+ /var/qtqa/sysadmin/puppet/sync_and_run.pl
Use of uninitialized value in numeric ge (=) at
/var/qtqa/sysadmin/puppet/sync_and_run.pl line 374.
Use of uninitialized value in numeric ge (=) at
/var/qtqa/sysadmin/puppet/sync_and_run.pl line 374.
Could not parse for environment production: Syntax error at '{'; expected '}'
at /var/qtqa/sysadmin/puppet/manifests/nodes.pp:13
Hi Sébastien,
I think you will need to upgrade your version of puppet.
Can you please try puppet =2.7.19?
On Ubuntu 10.04 (suggested platform for network test server), that can
be installed from this repo: 'deb http://apt.puppetlabs.com/ lucid main'
Actually, the bootstrap/ubuntu1004_bootstrap.sh script in the sysadmin repo was
supposed to already set up that repository for you.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] No recent commit in qt5 git?
Thiago Macieira said: On quarta-feira, 10 de outubro de 2012 15.01.56, Stephen Chu wrote: The last commit in http://qt.gitorious.org/qt/qt5 was a week ago. Is it frozen for release? No. It's blocked on failing tests. Help fix them and it will go in sooner :-) To elaborate ... you can track qt5 submodule update attempts from this dashboard: https://codereview.qt-project.org/#dashboard,1000191 If ever you see that qt5 hasn't been updated in a while, chances are you will find a change on that dashboard with some compile or test failures attached. There aren't many people looking into those failures nowadays, so help is always appreciated. Note: it's also fine for people to create and push qt5 submodule updates themselves (e.g. omitting the changes which are causing problems). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integration system problems
Peter Varga said: Hi all, I've noticed that merging patches into QtDeclarative repository doesn't really work, see https://codereview.qt-project.org/#change,36116 I suppose that the problem is in the integration system. The build log of my last attempt says HEAD is now at ae9859f crash fix in designersupport Initialized empty Git repository in c:/work/build/_testconfig/.git/ From git://bq-git.apac.nokia.com/codereview/qtqa/testconfig * [new branch] master - mirror/master fatal: The remote end hung up unexpectedly Build step 'Conditional step (single)' marked build as failure Build step 'Groovy Postbuild' marked build as failure Finished: FAILURE Does this repository (git://bq-git.apac.nokia.com/codereview/qtqa/testconfig) still exist? Could anybody inform me about the current state of the integration system? Is it working? That repository still exists. The system is generally working, but with a higher than usual rate of errors. Please go ahead and stage your change(s) again when you encounter system errors like that. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] bool QProcess::waitForFinished() Race Condition?
d3fault said: Unable to confirm the race condition, which is why I'm posting here instead of filing the bug report. Isn't there a race condition between calling QProcess::start() and QProcess::waitForFinished()? Can't the OS switch contexts at ANY TIME (in this case, between the start() and waitForFinished() calls)? Scenario: QProcess proc; proc.start(aVerySmallBinary); //OS switches contexts by sheer chance right here to the newly started process. If the process is short enough it could finish and exit cleanly before executing the following line bool finished = proc.waitForFinished(); //finished should be true, but in the race condition case it will be false because waitForFinished returns false ... if this QProcess is already finished (doc). That shouldn't be a race condition, because you didn't yield to the event loop between start() and waitForFinished(), so any events relating to the termination of the process have not been processed yet. If you were to stick a processEvents() between start() and waitForFinished(), then you'd have a race condition. Note the docs say ... if this QProcess is already finished, which is a different thing from whether the underlying native process is already finished :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Project CI System : Windows 7 machines with some problems
Sergio Ahumada said: Hi, We've found that Windows 7 machines are not up and running at the moment so we've decided to disable them from Qt Project CI system until we can fix them. This means that you might need to be a little bit more careful with what you stage during the weekend since they might introduce some errors due to this platform not being tested. This applies for all Qt5 modules and Qt 4.8 CIs. As soon as this problem gets fixed, we will enabled them again and will check/fix possible errors on Windows. The Windows 7 test configurations hosts are re-enabled again and no errors observed so far. There was a scripting error which caused the hosts to reboot into the wrong user account, sorry about that. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build Qt 5 with MinGW 4.7?
Andreas Holzammer said: Am 26.08.2012 16:23, schrieb Stephen Chu: On 8/26/12 10:03 AM, Stephen Chu wrote: Thanks for pointing out the build differences. I didn't realize there are so many different builds of the same MinGW version. Switching to mingw-builds get me further. But then I got this error: cp qmake.exe C:\Qt\5.0\qtbase\bin\qmake.exe g++: error: tmp/obj/debug_shared/arch.o: No such file or directory mingw32-make: *** [arch.exe] Error 1 Could not find output file: No such file or directory *** qtbase/configure exited with non-zero status. I went to qtbase\config.text\arch and manually ran mingw32-make to create the obj file in question. Then re-run configure and it worked. OK. I figured out that this error is caused by git in my PATH. I think sh.exe in git\bin is causing configure some issues. Removing git from PATH and configure finished without issue. qt5_tool requires git in PATH so I'll just have to remember changing PATH back and forth between clean up/update and configure. If you are using msysgit, there is a folder cmd, which has a forward batch file for just this issue. If you are using something else, you can also create yourself a forward batch file which has either a absolute path, or another way of finding the git.exe Just a small correction to avoid any possible confusion... Recently[1], this has been changed so that the git cmd folder also contains a git.exe. So please note that the latest versions of msysgit actually ship _two_ git.exe and no git.cmd or git.bat. [1] https://github.com/msysgit/msysgit/commit/893b221982321303e1a31b2098cd115c65ca49ab ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The containers in the containers branch
Oswald Buddenhagen said: For future reference, whoever is bypassing the CI to change the SHA1 of a branch should also issue a command like this to update the staging branch: ssh -p 29418 codereview.qt-project.org gerrit staging-rebuild --project qt/qtbase --branch containers , which I have now done, fixing the conflict. that's slight overkill. when you direct-push to a branch with no activity, you can just direct-push the staging branch as well - you just edit the command line, replacing heads with staging. Doing the staging-rebuild command would correctly take into account any changes which are currently staged (if any). If you do a force push to the staging branch, changes could be left in 'staged' state in the database but not actually be present in the staging branch. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The containers in the containers branch
Thiago Macieira said: On quinta-feira, 26 de julho de 2012 13.27.16, Thiago Macieira wrote: I'll abandon all changes still open in one week. They're cluttering my dashboard. Uh... André has approved one commit and tried to stage it, but it failed. Gerrit claims a conflict. Should be easy to fix... ... except that the commits are already rebased and there are no new commits in that branch. Can someone check to see what we're doing wrong? The conflict is with the staging branch (refs/staging/containers). That was 8141e34280a92088a527e0935765ad8ba8e92be8. It looks to me like the 'containers' branch has been used inconsistently with respect to CI, like somebody fast-forwarded it from 8141e34280a92088a527e0935765ad8ba8e92be8 to 7a0b8d580df8d6b0012d11f61299046682f4d18a rather than putting a merge commit through CI. Apparently, doing that will not automatically cause the staging branch to be updated. For future reference, whoever is bypassing the CI to change the SHA1 of a branch should also issue a command like this to update the staging branch: ssh -p 29418 codereview.qt-project.org gerrit staging-rebuild --project qt/qtbase --branch containers , which I have now done, fixing the conflict. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use static qt libraries
song.7@nokia.com said: Hi, Now we can build out the single libqt5.so (using ARM toolchain) by: OPTS += -static to create the static qt libs ar -x libQtXX.a to extract the .o files armlink --fpic --shared *.o -o libqt5.so to generate final single so But the readelf -s libqt5.so | grep UND: 4: 0 OBJECT WEAK DEFAULT UND _ZTI12QFocusHelper 5: 0 OBJECT WEAK DEFAULT UND _ZTI17QAbstractUndoItem 6: 0 OBJECT WEAK DEFAULT UND _ZTI19QStaticTextUserData 7: 0 OBJECT WEAK DEFAULT UND _ZTI22QItemEditorCreatorB 8: 0 OBJECT WEAK DEFAULT UND _ZTI26QAbstractDynamicMet 9: 0 OBJECT WEAK DEFAULT UND _ZTI28QNetworkConfigurati Does anyone know what is this mangled symbol _ZTIXX in C++ ? The 'c++filt' program can answer this. $ echo _ZTI12QFocusHelper | c++filt typeinfo for QFocusHelper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use static qt libraries
Liu Song.7 (Nokia-MP/Beijing) said: Thanks, are such undefined symbols normal ? And is there a way to fix it ? Right now, the only thing which comes to mind is if you have somehow mixed some -frtti and -fno-rtti objects. -Original Message- From: Mcgovern Rohan (Nokia-MP/Brisbane) Sent: Tuesday, July 24, 2012 11:58 AM To: Liu Song.7 (Nokia-MP/Beijing) Cc: Lan Peng-Peter (Nokia-MP/Beijing); Storm-Olsen Marius (Nokia-MP/Austin); development; thiago.macieira Subject: Re: [Development] Use static qt libraries Importance: High song.7@nokia.com said: Hi, Now we can build out the single libqt5.so (using ARM toolchain) by: OPTS += -static to create the static qt libs ar -x libQtXX.a to extract the .o files armlink --fpic --shared *.o -o libqt5.so to generate final single so But the readelf -s libqt5.so | grep UND: 4: 0 OBJECT WEAK DEFAULT UND _ZTI12QFocusHelper 5: 0 OBJECT WEAK DEFAULT UND _ZTI17QAbstractUndoItem 6: 0 OBJECT WEAK DEFAULT UND _ZTI19QStaticTextUserData 7: 0 OBJECT WEAK DEFAULT UND _ZTI22QItemEditorCreatorB 8: 0 OBJECT WEAK DEFAULT UND _ZTI26QAbstractDynamicMet 9: 0 OBJECT WEAK DEFAULT UND _ZTI28QNetworkConfigurati Does anyone know what is this mangled symbol _ZTIXX in C++ ? The 'c++filt' program can answer this. $ echo _ZTI12QFocusHelper | c++filt typeinfo for QFocusHelper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Project CI outage on 19th-20th July 2012
Rohan McGovern said: Hi all, Please be advised that tonight/tomorrow the Qt Project CI system will have a temporary outage for planned maintenance of a site UPS. The system will stop accepting new builds at: 18:30 UTC, 19th 20:30 CET, 19th 04:30 AEST, 20th The outage is estimated to last somewhere from 4-7 hours. It is fine to stage changes in this time, but they won't make progress until the maintenance is completed. The work is now completed and the system is operating as usual. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Project CI outage on 19th-20th July 2012
Hi all, Please be advised that tonight/tomorrow the Qt Project CI system will have a temporary outage for planned maintenance of a site UPS. The system will stop accepting new builds at: 18:30 UTC, 19th 20:30 CET, 19th 04:30 AEST, 20th The outage is estimated to last somewhere from 4-7 hours. It is fine to stage changes in this time, but they won't make progress until the maintenance is completed. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] buildsystem branches (about to be) integrated
Peter Kümmel said: On 26.06.2012 12:28, Oswald Buddenhagen wrote: On Mon, Jun 25, 2012 at 12:56:15PM +0200, ext Peter Kümmel wrote: Shadow builds [...] are broken: fix integrated Yes it works now. Thanks! Wouldn't this be a test case for the build server? Yes, certainly. Currently, shadow builds are tested only on Linux, and that configuration has source dir != build dir and build dir != install dir. Covering all of the source/build/install cases and having at least one shadow build each on the big three (Linux, Mac, Win) would be great. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Code of conduct.
Alexis Menard said: Hi, When I see recent behaviors, wording, comments on various mailing lists, blog posts, or IRC against major contributors or regular contributor I feel sad about it. I feel sad to hear bashing, complains in a way they should not be said, i.e. impolite, arrogant, aggressive. While I do understand people have strong opinion about feature A against feature B, QML vs C++, whatever against whatever, it is not a reason to not behave like educated person. I find it very demotivating especially when we all need to act as strong community to make Qt an even better framework. We don't all like each others but that is fine. But we are not forced to accept people polluting the environment, the professionalism on the project especially when it starts hurting motivation of people *actually* contributing to the project. These people are not welcomed. Should we have a code of conduct just like KDE or Gnome to specify what we expect from community members in term of behavior between each other? If people don't agree with this code of conduct then they should not participate to the project. It's not a law neither a removing liberty to people to raise their concerns, it just a way to make sure people will do it in a nice manner and if they don't they can just leave. When I read your mail, I tried to think which recent incidents you were referring to. I could only think of cases where non-contributors have been disrespectful of contributors. As far as I can tell, Qt Project contributors' interaction with each other is not a problem. Having a code of conduct may anyway be a good thing, but I don't think it would have made a difference to the behavior from non-contributors I think you're referring to in your mail. No matter what you do, jerks will be jerks ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] buildsystem branches (about to be) integrated
Oswald Buddenhagen said: moin, the buildsystem branch of qtbase is currently being integrated. this is ~120 commits worth of qmake project file fixes and cleanups. there are some changes to how modularization (in particular configure tests) is handled, and cross-building should be supported without hacks finally. the immediate impact: - lots of build scripts which employ various hacks will instantly break. don't panic and (mostly) just delete some code from them. use configure -xplatform spec -sysroot root make as you would intuitively expect. don't play tricks with funny qmake and make invocations. - the other modules will spit out lots of warnings now. *DON'T* do anything about them for now. i have patches prepared for all modules already. i will explicitly add the module owners to the reviews. *don't* stage anything yourself. once my patches are through, there will be still some warnings left. you'll be invited to fix them at this point. - some build configurations will work even worse than before until everything is integrated. the only variants which are expected to be safe are developer builds without -prefix and module-by-module builds with -prefix. catch me on IRC if something breaks for you and no obvious solution seems to help. but remember that not every breakage is due to this branch being integrated. ;) The qtbase merge has caused examples and tests to be silently disabled in all Linux and Mac CI builds. That is fixed by https://codereview.qt-project.org/29088 . Please refrain from staging risky changes until that is integrated. Windows builds and projects other than qtbase seem to be unaffected. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] buildsystem branches (about to be) integrated
Stephen Chu said: Is this buildsystem branch the one we get when we just clone qt5 clean? By that I mean if I go through the steps documented here: http://qt-project.org/wiki/Building-Qt-5-from-Git is that the same as this branch. Hi Stephen, No, the buildsystem branch has not yet reached the qt5 repository. The fact that a large qt5 update was merged around the same time as this email is just a coincidence. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Can't switch submodules to master and Mac build still broken
Stephen Chu said: I still can't get Qt 5 build on OS X for the merged code (https://codereview.qt-project.org/#change,28604) hasn't showed up in Qt 5 git default yet. So I want to to try moving modules to master to get the fixes by the instruction here: http://qt-project.org/wiki/Building-Qt-5-from-Git#181b27e32ae791e987cb19fced190543 With qt5_tool method I got: Examining: qt3d url: git://gitorious.org/qt/qt3d.git ### [qt3d] /usr/bin/git fetch --all Fetching origin Fetching gerrit ssh: connect to host codereview.qt-project.org port 22: Connection refused This last message indicates something is wrong with the configuration. It should be attempting to connect to port 29418, not port 22. Maybe you can try with standard git commands instead of qt5_tool? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8 autotests need attention; over 100 insignificant tests!
Thiago Macieira said: On quarta-feira, 13 de junho de 2012 17.32.43, Friedemann Kleint wrote: In Qt 5, this was solved by introducing the QFINDTESTDATA macro, but porting it to Qt 4 is a non-trivial task. https://codereview.qt-project.org/#change,28579 (Fix QLibrary test) and https://codereview.qt-project.org/#change,27579 (QApplication) illustrate what needs to be done for such cases: - Removing CONFIG -= app_bundle causes the Mac binary to be created in the test root folder - On Windows, cd up one level if the current working directory is 'debug' or 'release' in the test constructor Another solution we used to use is to add to the test's .pro file: DEFINES += SRCDIR=\\\$$PWD/\\\ Then all file references should be prefixed with SRCDIR. E.g: QFile f(SRCDIR ./testdata); Don't forget the space! It's an error to write SRCDIR./testdata in C++11. Please avoid this one in Qt 5. It makes the test not able to work when deployed to a device, unless you explicitly recreate the whole SRCDIR directory structure on the device or introduce a separate code path in the test. QFINDTESTDATA should be preferred, since it already searches the source directory. It is reasonable to fix the Qt 4.8 tests in this way, though. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] More CI people?
Girish Ramakrishnan said: Hi QA team, I think today is the second day, CI is getting stuck. I wish I could just restart the integration. Usually, it's easy to let Rohan know if we are somewhere in his timezone. But if we are not in his timezone, it's quite frustrating. There's also the case where it's a huge time save to abort a current integration, if it's known in advance that it's going to fail. With that in mind, would it be possible for someone to have extra QA backups in mostly all timezones. Maybe there's already someone but I don't know who they are. I know only rohan since he is active on irc. In Europe, we also have Sergio (sahumada on IRC) and Jyri (tahtela on IRC). However, it seems to be holiday time in Europe. I am pretty sure the issues from last two days would have been resolved more quickly otherwise. And yes, I volunteer if required. Great :) That will mean getting involved in CI-related code reviews and bug reports, and being added to some list to receive error alerts from the system, etc. So if you like, just let us know and we can start adding you to these. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Becoming a Tier 1 platform and the CI System
Sean Harmer said: On Wednesday 06 June 2012 12:02:23 lars.kn...@nokia.com wrote: On 6/6/12 1:56 PM, ext Sean Harmer sean.har...@kdab.com wrote: I understand and integrating into the CI system would seem by far the most sensible way to go in terms of maintainability, reducing man-power at release time and preventing introduction of regressions. Absolutely. But that requires that someone steps up and creates a CI infrastructure we can use. The current one is based on a commercial solution that Nokia unfortunately can't hand out to everybody. It should however be possible to use the existing scripts (with some modifications) on Jenkins. Can you elucidate on what you mean by someone steps up and creates a CI infrastructure please? Do you mean that the existing one needs hooks adding to allow additional external nodes to be plugged in? Or that new hardware, hosting, CI tool and everything else is needed from fresh? Or something in between? It means that the current CI infrastructure is operated by Nokia and can't have build nodes plugged in from outside of Nokia premises. So, if you need to manage your own build nodes, there is currently no way to integrate with the Qt Project CI system. Fixing this is a significant project which I am not aware of anyone currently working on :( However, if testing (at least compile testing) for your platform can be done with commodity hardware and freely available software, and is not particularly demanding in other respects, there's a possibility of making progress with the current setup. If that's the case, please create a task with some of the technical details on https://bugreports.qt-project.org/browse/QTQAINFRA . ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary incompatible changes to Qt 4.8
Turunen Tuukka said: If feasible, I would like to see both Mac OS X 10.8 and Windows 8 (to the extent it is know at that time) working in the 4.8.3 release, as well as Ubuntu 12.04. In addition to making the obvious fixes it would be important to do regular CI on these platforms as well, if possible. Do you think it is feasible? Are you asking for those three platforms to be added to the Qt Project CI? Or more asking if it is possible, which you answered to ;) Unless a configuration is not in the CI system, I do not see it possible to say it is a reference / Tier 1 configuration. It can be made to work, but is prone to errors. As 4.8 will be a long lived platform, it would be good to add these new operating systems to the CI and testing system. In case of a 'normal patch release' this naturally would not be so important. Do you think these can be added after 4.8.3 (which is planned to be released in August, depending a bit on the 5.0.0 schedule)? Right now, Ubuntu 12.04 is the only one to which I can give a confident yes. For OSX 10.8 and Windows 8, we need more data. I'm trying to get a better answer for those, stay tuned. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build broke on Windows 7 64bit, whatever out-of-source or in-source-tree
Loaden said: Windows SDK 7.1 ActivePerl 64bit Python 2.7.3 Any comments? Maybe some comments if you share the build log :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Current qt5 version from git does not compile with VS2010
Helmut said: Some days ago I wrote: a few days after the alpha release of qt5 the git version (with git pull qt5; perl init-repository -f) stopped to compile with Visual Studio 2010. Compiling qqmlopenmetaobject.cpp results in this error: d:\qt\qt5\qtdeclarative\include\qtqml\5.0.0\qtqml\private\../../../../../src/qml/qml/v8/qv8_p.h(42) : fatal error C1083: Cannot open include file: 'private/v8.h': No such file or directory I found what the problem was: I am using msys git which has problems with file permissions. After adding git config-global core.filemode false the checkout was ok. But I still cannot compile. I did in my qt5 clone (D:\Qt\qt5): - git submodule foreach --recursive 'git clean -dffx' git clean -dffx - git pull - perl init-repository -f - configure -prefix %CD%\qtbase -confirm-license -opensource -make libs -nomake tests -nomake examples -no-incredibuild-xge -release -fast 1 configure.log 21 - perl build 1build.log 21 Hi Helmut, Would you like to try removing jom.exe from PATH and trying again? There is a known build system issue https://bugreports.qt-project.org/browse/QTBUG-23376 which can cause some errors of this nature. In theory, the build script already has a workaround, but nmake may be worth a try for you. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtphonon's status.
Stephen Kelly said: On Thursday, May 17, 2012 18:31:43 lars.kn...@nokia.com wrote: I don't want to maintain a fork of phonon on qt-project if the developers decided they want to continue within the KDE infrastructure. phonon should have one upstream place where it is being developed. I'd say let's deprecate the module and remove it from qt5.git. We can keep the code around for some time if someone sees some value in it. I don't understand this part. What's the difference between webkit and phonon in this regard? One difference is that qtwebkit in Qt5 is sometimes updated by the QtWebKit developers to point to a snapshot expected to work with the rest of qt5.git (so that e.g. the qtwebkit SHA1 pointed to by the qt-v5.0.0-alpha1 tag in qt5.git is accurate). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bugreports for Playground projects
Laszlo Papp said: The Qt Project lacks Jira maintainance man power, or what is the reason behind ? I think so ... certainly nobody seems passionate about it, at least. And nobody has it as one of their primary responsibilities as far as I know. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build issue with configure -developer-build for qtbase?
Thiago Macieira said: I am guessing you all have transitioned to 64 bits for your build system, etc. What is your policy statement on 32 bit systems? Try not break them? They deserve to get broken? ??? For me I will probably just transition my work to 64 bits even if our legacy stays 32 bits for a while longer. We have not all transitioned. In fact, I'm almost sure that all the CI builds are done on 32-bit. Not quite, there's a mixture of 32-bit and 64-bit. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cross build failed of unsupported/win32-g++-cross mkspecs
k blammo said: On 16/05/2012 06:42, Loaden wrote: Hi, All! I want cross build Qt5.0 on Ubuntu 12.04, because I deleted all Windows OS on my laptop. But now I have a trouble of the cross build. So, I need you help in here. I just noticed this at the end of your configure log: + /home/loaden/qpSOFT/Projects/BuildQt5-w32/qtbase/bin/qmake /home/loaden/qpSOFT/Projects/Qt5/qt.pro What is that doing there? You really should be running make at that point, not qmake. That is being run by configure. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Current qt5 version from git does not compile with VS2010
Helmut said: Hi, a few days after the alpha release of qt5 the git version (with git pull qt5; perl init-repository -f) stopped to compile with Visual Studio 2010. Compiling qqmlopenmetaobject.cpp results in this error: d:\qt\qt5\qtdeclarative\include\qtqml\5.0.0\qtqml\private\../../../../../src/qml/qml/v8/qv8_p.h(42) : fatal error C1083: Cannot open include file: 'private/v8.h': No such file or directory The include directives are: -I..\..\..\qtbase\include\QtCore\5.0.0 -I..\..\..\qtbase\include\QtCore\5.0.0\QtCore -I..\..\..\qtbase\include\QtCore -I..\..\..\qtbase\include\QtNetwork -I..\..\..\qtbase\include -I..\..\include\QtQml\5.0.0 -I..\..\include\QtQml\5.0.0\QtQml -I..\..\include -I..\..\include\QtQml -I..\..\include -Itmp -Ianimations -Idebug -I..\..\..\qtbase\mkspecs\win32-msvc2010 I have a v8.h in: D:\Qt\qt5\qtjsbackend\include\QtV8\5.0.0\QtV8\private D:\Qt\qt5\qtjsbackend\src\3rdparty\v8\include D:\Qt\qt5\qtjsbackend\src\3rdparty\v8\src D:\Qt\qt5\qtwebkit\Source\WebKit\qt\v8\ForwardingHeaders The first one contains: #include ../../../../../src/v8/../3rdparty/v8/include/v8.h Hi Helmut, Generally speaking, Qt5 is continuously tested with MSVC2010, and it is able to be compiled successfully. Here is a recent, passing compile log: http://testresults.qt-project.org/ci/Qt5_master_Integration/latest-success/win32-msvc2010_Windows_7/log.txt.gz Maybe you could provide your full compile log, for comparison? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
Girish Ramakrishnan said: Hi, On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: The change landed. For some reason, the ci is failing compile in all other modules. Works locally with shadow builds but not on CI. I am on it. Fix is integrating: https://codereview.qt-project.org/#change,25570. Sorry for blocking the CI. Ideally this would have been caught by the reverse dependency qtdeclarative test in qtbase's CI, but apparently the issue only affected shadow builds, which weren't covered. We'll add a shadow build revdep-qtdeclarative config to prevent similar issues in the future. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.0 beta and final timelines
casper.vandonde...@nokia.com said: In the meantime we can/should think about doing another alpha. Thiago proposed that one option here could be to simply release the first source package that works on all platforms as the second alpha. Like that we don't use any additional resources and time on creating that second alpha. Cheers, Lars I assume we would want qt5.git integration to happen first? That hasn't happened since April 18th, a lot of changes are still waiting for that to happen (I think all the Qurl/QRegExp) stuff etc. I think that we do ... the lack of integration is a genuine reflection that the master of all modules are currently not working together. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [CI] reverse dependency testing
A while back, it was requested that the Qt Project CI should reject incoming changes to QtBase if they would cause compile or autotest failures in QtDeclarative. That is now implemented, which should reduce the risk of accidental source or behavior incompatible changes in qtbase. However, if you need to _deliberately_ do some changes in qtbase which would break qtdeclarative, it's necessary to do some additional steps. These are documented, along with a few other bits of information, on the wiki at http://wiki.qt-project.org/CI:_Revdep . The reverse dependency testing is not yet set to enforcing, so it won't block changes. Assuming no objections, we'll probably set it enforcing on this Thursday, 3rd May (if it is passing at that time). Similar reverse dependency testing can be added for other modules on request. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [CI] reverse dependency testing
Storm-Olsen Marius (Nokia-MP/Austin) said: Looks good, but please move the details over to the other wiki. The Mediawiki installation at wiki.qt-project.org has been deprecated since DevNet was moved over and we got www.qt-project.org/wiki. Thanks, then there should be some message on the deprecated wiki, e.g. where the Login procedures have been improved message is now. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Can't build docs anymore!
Loaden said:
I don't think this is a good idea, realy.
We should find out a better way.
Yes, that was only a workaround.
qtdoc/doc/doc.pri should be modified to avoid building such a huge
command. As far as I know, it is valid to set an environment variable
in one make command and make use of it in the next, so I don't think
this needs to be built as a single huge command.
Maybe even the following patch is already enough, but I didn't test it:
diff --git a/doc/doc.pri b/doc/doc.pri
index c11b14d..fd41803 100644
--- a/doc/doc.pri
+++ b/doc/doc.pri
@@ -18,7 +18,7 @@ $$unixstyle {
SEP =
} else {
SET = set
-SEP =
+SEP = $$escape_expand(\\n\\t)
}
# The module names correspond to the names of files in qtbase/mkspecs/modules
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
jason.mcdon...@nokia.com said:
Random question of the day: do you happen to have stats about how
often those insignificant tests actually fail? That should help to
figure out which ones are actually working, and therefore should not
be marked as insignificant.
I'm glad you asked. I spent some time yesterday and today doing that
analysis for the 40-odd insignificant tests that had no Jira task associated.
I used the data from the last eleven CI runs for each module (times eight
configs for which autotests are executed). That's not hugely statistically
significant, but it's not that easy to pull large numbers of build logs out
of the CI system manually through the web interface. (Any CI folks who can
tell me how to extract/search all the stored logs?)
I'm using this pattern (which has some minor problems not relevant for
any test I've looked at so far):
from=02238
to=02538
prj=QtBase_master_Integration
cfg=win32-msvc2010_Windows_7
test=tst_QLocale
trailing_lines=3
for i in $(seq -w $from $to); do
echo $i:
wget --quiet -O -
http://testresults.qt-project.org/ci/$prj/build_$i/$cfg/log.txt.gz |
zcat |
egrep -A $trailing_lines Testing $test ||
echo did not run
echo
done 21 | tee results_${test}.txt
... and scanning at least one hundred logs.
Having a transparent caching proxy between self and
testresults.qt-project.org helps a lot.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
marius.storm-ol...@nokia.com said: On 04/11/2012 07:49 AM, ext lars.kn...@nokia.commailto:lars.kn...@nokia.com wrote: ** insignificant tests ** We still have quite some tests (around 110 in total) marked as insignificant. This means they will be ignored by the CI system. Any help to reduce this number would be great. I've grepped through all the modules to create a list of these insignificant tests, and listed them below. Please note that a test marked as insignificant in essence provides us with zero coverage, since all results from those test cases (although run) are completely ignored. Yes, we used to have a (quite large) list of black-listed tests for Qt 4 as well. However, back then we could mark only a test function as black-listed, while the rest of the testcase would still provide some test coverage. That's an important difference. IMO, if there are tasks we cannot repair, due to the tests being inheritly unstable, or our infrastructure not being able to handle it, then we should remove them. Having test cases which adds no value, but is hard to see unless you find the insignificant_test keyword, is bad since you don't know exactly what the coverage is and where it is lacking. How should we mark that we are working on a specific test case to fix the instability etc, to ensure we don't do double work? Suggestions? Is a Jira task with 'module: insignificant test name' good enough? Tests marked as insignificant _should_ have had a task raised when they were marked as such - for those, it would make sense for the person who is working on it to assign the task to themselves and/or add a comment. In reality it seems like quite many tests were marked as insignificant with no task raised, it would probably make sense to raise a task when beginning work on it. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The qtbase CI should run the qtdeclarative tests
Knoll Lars (Nokia-MP/Oslo) said: On 3/19/12 2:11 AM, ext Rohan McGovern rohan.mcgov...@nokia.com wrote: marius.storm-ol...@nokia.com said: While it's not normal to do this type of dependency lock for upwards dependencies, i think in this case we should indeed do the extra checking. Not just because QtDeclarative is such an important tech for Qt5, but also because it's a very good test case for QtBase. What would be the proposed workflow to resolve this situation? - I have a change in qtbase which I can't push because it breaks a qtdeclarative test. - I have a fix to the test in qtdeclarative but I can't push it because it doesn't pass without my qtbase change. One solution I can think of is to introduce a %reverse_dependencies in sync.profile, used for CI and nothing else, which can control the SHA1 of qtdeclarative used while testing qtbase. The easiest way is probably to do it in 3 stages: * Pin the SHA1 of qtbase in declarative * Submit the qtbase change * Unpin the sha1 and submit the declarative fix. I don't understand this suggestion. If qtdeclarative's sync.profile has pinned to a particular qtbase SHA1, that shouldn't affect the with declarative qtbase CI configuration, right? So how does it resolve the deadlock? Or do you think declarative's sync.profile _should_ affect the with declarative qtbase CI config? That means pinning a qtbase SHA1 in qtdeclarative effectively disables this config, since you'll be testing qtdeclarative's requested qtbase SHA1 which does not include the incoming qtbase changes. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The qtbase CI should run the qtdeclarative tests
marius.storm-ol...@nokia.com said: While it's not normal to do this type of dependency lock for upwards dependencies, i think in this case we should indeed do the extra checking. Not just because QtDeclarative is such an important tech for Qt5, but also because it's a very good test case for QtBase. What would be the proposed workflow to resolve this situation? - I have a change in qtbase which I can't push because it breaks a qtdeclarative test. - I have a fix to the test in qtdeclarative but I can't push it because it doesn't pass without my qtbase change. One solution I can think of is to introduce a %reverse_dependencies in sync.profile, used for CI and nothing else, which can control the SHA1 of qtdeclarative used while testing qtbase. Another is to skip the testing of qtdeclarative in qtbase branchname's CI if qtdeclarative's sync.profile does not contain qtbase = refs/heads/branchname. The extra time used for checking both repos will give much greater stability as a whole. Well, we don't really know that. Note that introducing qtdeclarative into the qtbase tests means that both directions of breakage are now possible (i.e. not only can qtbase changes block qtdeclarative's CI, but now qtdeclarative changes will be able to block qtbase's CI - though it should be unlikely). However it's certainly reasonable to expect that, and give it a try. Maybe the fast platforms can do the extra checking, while slow platforms still handle only QtBase? At least we will capture most compile issues? I think we'd start with adding new configurations rather than modifying existing ones. e.g. as there is currently a linux-g++-32 Ubuntu 10.04 x86 configuration for qtbase, there could be a new linux-g++-32 Ubuntu 10.04 x86 with declarative configuration. Doing it that way also means the with declarative configuration can run just the qtdeclarative autotests (we assert that there's no need to run the qtbase autotests again), theoretically not increasing the overall runtime. Unfortunately there's probably not enough resources to do that for some platforms (like Mac). (The CI rules might get very complicated though.) Yes, in some ways I feel this is adding complexity to the test setup to work around a false simplicity in our source code setup. We claim that Qt is modular, but actually we know some parts of it are not really, so we add gates to enforce some level of de-modularization. Rohan/Sergio, what will be the turn-around increase if we always test Declarative together with QtBase? The runtime should be somewhere between the current runtime of qtbase, and the qtbase runtime plus the qtdeclarative runtime. Anything more would be speculation ... but I don't think the runtime would be a big issue :) Anyway, overall I think it's worth a try, but we should accept that this could also create some new problems as well as solving some existing ones. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] cast ... increases required alignment of target type [-Werror=cast-align]
Thiago Macieira said: On quarta-feira, 14 de março de 2012 21.37.23, lars.kn...@nokia.com wrote: Possible options: a.) fix the underlying warning (probably very tough for alpha one) b.) remove -Wcast-align from the headersclean.pri for the alpha one? c.) don't mind that qtbase does not compile for MIPS in the alpha d.) ??? I'd go for (b), but if possible only for MIPS. That is exactly what's done for ARM, it should be fine to do it for MIPS too. http://codereview.qt-project.org/20033 does this. Note that most users do not build the tests. So the build will not stop for them. -Werror should never be enabled on non-developer builds. You did approve the change which enables it, though :) 7e970eb58c71dc08981575c648a04d258dbf0684, I mean. Do you think this test should now only be enabled on developer builds? IMHO that goes against the intent that the real headers we ship in a publicly-configured Qt are free of warnings. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Kurt Korbatits for approver
jason.mcdon...@nokia.com said: All, I'd like to nominate Kurt Korbatits for approver status. Kurt worked on Qtopia, Qt and Qt Mobility from 2005 to 2010 and rejoined Nokia's Brisbane team in late 2011. Since then he has been working on improving the state of Qt's autotests with a particular focus on getting the tests working for embedded and shadow builds and has achieved significant improvements in test results for these. Kurt's past experience with Qt also gives him specialized knowledge of multimedia, performance and building embedded systems using Qt. Seconded :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
Richard Moore said: On 12 March 2012 17:56, kent.han...@nokia.com wrote: Besides flaky tests, we also have the general/recurring problem of changes going into qtbase that break qtdeclarative (and possibly/likely other modules). While I realize it's time-consuming for everyone to manually build and run the qtdeclarative tests (or entire qt5.git) when you're working on qtbase, please at least take the time to consider how your change might affect other modules. If you're unsure and/or would like someone else's opinion on the possible impact, feel free to send an email to this list, or ask on IRC. Thanks. Do you have any idea of how many of these were due to QtDeclarative making assumptions that aren't part of the defined API, vs how many were changes in expected behaviour? Here's the commits which were needed: http://codereview.qt-project.org/18941 - 406f741 Remove pin of qtbase for qtdeclarative. - the one removing the pin, not actually resolving any test failures. http://codereview.qt-project.org/18909 - 16e29f3 Remove unneeded dependencies to QtWidgets and QtOpenGL - I don't think this one resolves any test failures. http://codereview.qt-project.org/19656 - c787809 Mark presumed unstable test as insignificant. - marks tst_qquickpixmapcache as insignificant, doesn't actually resolve the problem, so the real issue may not yet be understood http://codereview.qt-project.org/19552 - dda130f Fix MouseArea autotest. http://codereview.qt-project.org/19534 - 6cf36b2 Fix tst_qquicktextedit. http://codereview.qt-project.org/19427 - cb1ff7a Fix double click handler in QQuickItem. - all of these were failing due to changes in double-click semantics, apparently a bug fix: commit b371f3f943703840d0dfbe30505018bcca06e260 Author: Laszlo Agocs laszlo.p.ag...@nokia.com Date: Tue Mar 6 16:09:09 2012 +0200 Fix double click handling. Until now double clicking in Qt 5 resulted in the following sequence of mouse events: pressed, released, double clicked, released. This is wrong, the press belonging to the second button down is missing. In Qt 4 that pressed event is present. There were also some follow-up commits to this one, I am not sure exactly which one triggered the problems. Probably all of the failing tests were created or updated while qtbase had the buggy double-click behavior. Then they started to fail when the bug was fixed in qtbase. It's still unclear to me if the actual behavior matches what is documented, e.g. http://doc.qt.nokia.com/5.0-snapshot/qwidget.html says If the user double-clicks, the widget receives a mouse press event, a mouse release event and finally this event instead of a second mouse press event, vs Laszlo's comment in tst_qquickmousearea, press, release, (click), press, double click, release. http://codereview.qt-project.org/19598 - cbb7f8b Skip test that accesses deleted QML engine - apparently the test reads invalid memory, but doesn't actually crash on most platforms. It might be that the qtbase changes, due to changing the layout of a few things in memory, caused it to start crashing on at least one platform. http://codereview.qt-project.org/19636 - 2553575 Fix flakiness in qquicklistmodel autotest - the test was buggy, it had a race condition which may have been triggered by someone making some code faster, or perhaps reducing the amount of round trips through the event loop required for one tested condition to become true. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] cast ... increases required alignment of target type [-Werror=cast-align]
Thiago Macieira said:
On quarta-feira, 7 de março de 2012 09.34.35, Rohan McGovern wrote:
Does anyone have a suggestion on how to fix this warning?
This code in qlist.h:
409: template typename T
410: Q_INLINE_TEMPLATE void QListT::node_destruct(Node *from, Node *to)
411: {
412:if (QTypeInfoT::isLarge || QTypeInfoT::isStatic)
413:while(from != to) --to, delete reinterpret_castT*(to-v);
414:else if (QTypeInfoT::isComplex)
415:while (from != to) --to, reinterpret_castT*(to)-~T();
416: }
src/corelib/tools/qlist.h:415:28: error: cast from
‘QListQVariant::Node*’ to ‘QVariant*’ increases required alignment of
target type [-Werror=cast-align]
There is an increased alignment requirement in there. However, the side of
the
branch being considered, line 415, is never executed because isLarge == true.
So this warning is a false positive on a line that gets never compiled.
Thanks, so can we use #pragma GCC diagnostic to selectively silence
warnings like this? There doesn't seem to be much precedent for it so
far (just one usage I can find in qatomic.h).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] cast ... increases required alignment of target type [-Werror=cast-align]
Does anyone have a suggestion on how to fix this warning?
This code in qlist.h:
409: template typename T
410: Q_INLINE_TEMPLATE void QListT::node_destruct(Node *from, Node *to)
411: {
412:if (QTypeInfoT::isLarge || QTypeInfoT::isStatic)
413:while(from != to) --to, delete reinterpret_castT*(to-v);
414:else if (QTypeInfoT::isComplex)
415:while (from != to) --to, reinterpret_castT*(to)-~T();
416: }
...when compiled for ARM, causes this warning (or error with -Werror):
src/corelib/tools/qlist.h: In member function ‘void
QListT::node_destruct(QListT::Node*, QListT::Node*) [with T = QVariant]’:
src/corelib/tools/qlist.h:738:5: instantiated from ‘void
QListT::dealloc(QListData::Data*) [with T = QVariant]’
src/corelib/tools/qlist.h:714:9: instantiated from ‘QListT::~QList()
[with T = QVariant]’
src/corelib/statemachine/qstatemachine.h:81:59: instantiated from here
src/corelib/tools/qlist.h:415:28: error: cast from ‘QListQVariant::Node*’
to ‘QVariant*’ increases required alignment of target type [-Werror=cast-align]
do not compile with -Wcast-align may be a valid answer, but it would
be good to hear from someone who can confidently say whether or not this
issue can actually harm us in practice.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Project CI having a bad day
Sergio Ahumada said: Hi, The Qt Project CI is having some problems as we speak, and most likely will continue like it for next couple of hours. Changes in INTEGRATING state will be either integrated or rejected once the CI is back. We'll keep you informed about the progress. We now patiently wait for a 1TB fsck to complete on one server, as well as preparing a restore from backup in case unrecoverable data corruption is found. Thank you for your patience. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Project CI having a bad day
Rohan McGovern said: Sergio Ahumada said: Hi, The Qt Project CI is having some problems as we speak, and most likely will continue like it for next couple of hours. Changes in INTEGRATING state will be either integrated or rejected once the CI is back. We'll keep you informed about the progress. We now patiently wait for a 1TB fsck to complete on one server, as well as preparing a restore from backup in case unrecoverable data corruption is found. Thank you for your patience. Hi all, Service is restored and we are working on clearing the backlog of changes. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtwebkit-examples-and-demos.patch
Philip Ashmore said:
Hi there.
Please find attached a patch for qtwebkit-examples-and-demos that allows
the build to complete on Debian Wheezy amd64.
Please also note that this patch includes a previously submitted patch,
not yet applied.
Also, examples/webkit/fancybrowser/fancybrowser.pro contains a
TARGET.EPOCHEAPSIZE in symbian{} that seems to contain invalid utf-8
characters.
Hi Philip,
Are you able to push your patches into the gerrit code review tool at
http://codereview.qt-project.org ?
(documentation at http://wiki.qt-project.org/Code_Reviews )
Patches generally can't be accepted unless the copyright holder has
signed a Contributor License Agreement (CLA), which is managed through
the code review tool. Loose patches to mailing lists or to the bug
tracker may not make satisfactory progress.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use make before you push and stage
Giuseppe D'Angelo said:
On 30 January 2012 03:51, Rohan McGovern rohan.mcgov...@nokia.com wrote:
I don't think it is a good idea.
Having errors with incremental builds which go away when you do a clean
build is one thing, but there are also some issues which _should_
cause the build to fail, but don't if you only do incremental builds.
Thinking out loud - mad idea.
Does anyone have (or knows how to extract from gerrit) stats about how
many stages are requested on average during the week?
All of the builds are stored in git under
refs/builds/${destinationbranch}_${timestamp} , so I guess you can use
that to figure out the approximate starting time of each build, and
how many commits are introduced in each build (just ask git for the list
of commits which are in the current build and not in the previous
build).
That would be an interesting thing to analyze regardless of the
discussion in this thread.
Would it be possible to do incremental builds when the one
sub-repository is more active, and full builds otherwise (with
patches that are merged in if and only if they pass the full build)?
For instance, if qtbase is more active during CET working hours, one
could think of having incremental builds from 8.00-12.00 and
15.00-18.00, with a full build at 12.00 (~3h, till 15.00) and other
full builds starting at 18.00 and going on overnight?
It's possible, so the question is whether or not it's a good idea.
Personally I think the build system should support incremental builds
correctly before we can use them in the codereview CI.
We already have plenty unreliable components in the CI, let's avoid
adding more.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Tests, Shadow-Build and Cross-Compilation
Holger Hans Peter Freyther said: On 01/29/2012 09:21 PM, Olivier Goffart wrote: The other part/wish would be to always have deployment targets for the testcases and generate a run script or such as part of the installation. There is QFINDTESTDATA and QTest::qFindTestData that have been added recently, I think for this reason. Have you heard of them? hi, no I did not hear of it, when trying to resolve the shadow build issue in xmlpatterns i just grepped qtbase/tests and the SRCDIR solution popped up. Sadly QFINDTESTDATA is not enough for xmlpatterns, e.g. the checkxmlfiles test will try to find all .xml/.ui/.xhtml/.qrc... files in the module (this also means that by moving this test out of Qt there is less test data). The xml patterns test uses QDir(QL1String(../../../)) to find the files recursively and QFINDTESTDATA determines that this will work with the build directory. Should we just call it a crappy test as the testdata is not well defined? I would say that the test is broken. It is valid sometimes to have tests scanning the source tree like this, but in that case they must gracefully disable themselves when the source tree is not available. The other question is _should_ all tests be deployed or how do you plan to run tests on the device? Shane mentioned in Qt4 we were using DEPLOYMENT and a tool to parse that from the .pro files for WinCE and Symbian deployment. MeeGo/Harmattan use packaging (rpm or deb) for all deployment. In that setup, to run tests on a device you need to make sure that the test and its testdata all install themselves during make install. That seems to be becoming (or already is) the standard method of test deployment in Qt5. So, basically, all tests should either install themselves and all their testdata, or should install nothing (which can be interpreted as flagging the test as undeployable). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Tests, Shadow-Build and Cross-Compilation
Olivier Goffart said: On Sunday 29 January 2012 21:13:25 Holger Hans Peter Freyther wrote: Hi all, I finally got around to play with my personal jenkins[1] setup again, specially to learn (and be kind of an example on how a non Tier1 platform could ever become one). There are some issues and I would like to discuss how these can be solved in a way that doesn't look like an ad-hoc solution and that might scale. I will mumble about the Problems, the Ad-Hoc solutions and muse about a fix... Problems: Shadow builds: I always liked shadow builds as I could have several Qt configurations but a command/shared source directory (e.g. X11, QWS, for i386 and ARM). It is quite common for tests to break in shadow builds (the QA page in the wiki discourages this as well). Yes, the wiki recommands not to use shadowbuild because it often do not work. (I had the problem today again while trying to run qlibrary autotest) Hopefully this advice can be removed at some point. There are 1-2 people gradually working on fixing up all the tests to work for shadow builds, at which point it will be blocking in the codereview CI. About half the modules (the simpler ones) are already set up for shadow builds, they can be seen at http://wiki.qt-project.org/Public_Autotest_Infrastructure#linux-g.2B.2B_shadow-build_Ubuntu_11.10_x86 [...] Musing: So somehow cross-compilation and shadow-builds suffer from the same problem that accessing files from the source directory with a relative path. One proposal would be to use something like 'QDir::addSearchPath(testdata, SRCDIR)' and have it set to the path of the .pro file, and access everything using the prefix. Danimo mentioned that this will fail for multimedia that might not use the Qt resource system. So we might want to have a method in the testlib to resolve a path like testdata:foo to a proper path? For cross compiling one could change the testdata prefix with a command line option or environment variable? The other part/wish would be to always have deployment targets for the testcases and generate a run script or such as part of the installation. There is QFINDTESTDATA and QTest::qFindTestData that have been added recently, I think for this reason. Have you heard of them? Yes they were added exactly for this. There is also TESTDATA in .pro files to install test data files, but this is not really good enough to be documented other than a comment in testcase.prf. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use make before you push and stage
Jedrzej Nowacki said: You are assuming that we need to test every patchest which would be nice, but it is not necessary. A bot-tester would be sufficient, it might be added as a reviewer by human reviewer only if it makes sense. I like this idea and had been thinking along these lines for a while. Similar to how all changes at the moment automatically end up with Qt Sanity Bot as a reviewer, a developer could explicitly add other test bots as reviewers to their change. This could also include testing which takes too long to perform in the main CI. If anyone thinks this is _not_ a good idea then I would be interested to hear the reasons :) We do not need to test every platform, only the fastest one. The point of this system would be to reduce failures count because of simple mistakes; like broken compilation because missing function. It doesn't have to find problems related to differences in compilers. Another thing is, can it happen in parallel? Do we use 100% of test server capacity? Btw. I do not think that ccache is a hack, I was using it for a few months working on Qt and it was ok. Currently, there is no way to test properly difficult patches without staging them. Only CI knows how to test Qt correctly, which tests are flaky, which tests may be ignored, which may be run in parallel and which needs to be run without touching mouse/keyboard because of focus issues. Parsing output of make check is not funny too. Everything that improves that situation even slightly is awesome. I agree with the main point of this paragraph but would like to correct a couple of minor things: Only CI knows ... which tests may be ignored = mostly false, the build system knows this. CONFIG+=insignificant_test in a .pro file causes `make check' to ignore the exit code of a testcase, both in CI and when you run `make check' locally. The exception is that the CI system can be configured to ignore _all_ autotests for a particular configuration, and nothing in the tested repo tells you this. Only CI knows ... which may be run in parallel = none of them are run in parallel by CI. If you are thinking of CONFIG+=parallel_test: that was added for this utility http://labs.qt.nokia.com/2010/10/29/making-auto-testing-easier/ by Yoann Lopes, and as far as I know has never been used by any other tools. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion for new CI: early warning for qt5.git
Olivier Goffart said: On Friday 27 January 2012 09:09:46 Kent Hansen wrote: [...] If there is no quick fix, the last resort is to pin one or more of the dependencies' to a particular SHA1 (e.g. from the qt5.git submodule) in the sync.profile until the issue has been resolved, then unpin it again later. Why is that the last resort? This seems totally normal and was the whole point of modularisation: Differents modules can be developped at different speed. When this was discussed back when CI was being established on modularized Qt, the consensus[1] was that the goal should be to keep the head of all modules working together as much as possible - that's why people have been discouraged from using anything other than the head of their dependencies in sync.profile. [1] which in this case really means the thing that someone said and no-one objected to :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion for new CI: early warning for qt5.git
Kent Hansen said: Hi, Sometimes there are changes to qtbase that the author and/or reviewers strongly suspect will break one or more modules on top of it (e.g. in qt5.git). For example, source-incompatible changes (removing QEventLoop::DeferredDeletion), or changes to the meta-type/QObject internals (which qtdeclarative is relying heavily on). When such a change goes into qtbase, you only get the failure for the dependent modules the next time you stage something (anything) in that other module; suddenly the module no longer builds, or tests seemingly unrelated to the developer's own change start failing. This means developers will be scratching their heads and spending time tracking down what was the actual cause of the failure (first in their own changes/module, then in the dependencies). It also means that the CI is wasting cycles on subsequent (failed) attempts to fix the failure, which is disruptive to everyone trying to stage new and unrelated changes. If there is no quick fix, the last resort is to pin one or more of the dependencies' to a particular SHA1 (e.g. from the qt5.git submodule) in the sync.profile until the issue has been resolved, then unpin it again later. An idea to avoid such disruption would be a CI where you can try to merge your change, and it will build all of qt5.git with it (_and_ run all the module's tests). This could be a separate button in Gerrit, for example. You then get a report in Gerrit with the status from the complete build tests run. Even if everything succeeds, the change will not actually be integrated; this would just be a tool for getting an indication of potential inter-module problems with your patch. If there are problems, the developer can then either fix the affected modules in advance if possible, or at least give a heads-up and/or prepare patches that will fix the upcoming breakage in the other modules. What do you think? As Joao mentioned, this relates to a dry run of the CI feature. I think that we need a method of requesting that some test procedure is run over your change in gerrit, without also testing some set of everyone else's changes at the same time, and without requesting that the change is actually merged into the repository at the end of the test. If we have that, then we can add all sorts of test procedures into that workflow. test all of qt5 on top of my change would be a natural test to provide. You mentioned a button in gerrit, but what do you think of soliciting machine reviewers instead, as you currently do for humans? e.g. 1. push change to gerrit 2. go to web UI, add reviewer named something like Test : qt5.git tester : compile/test all of qt5.git with your change 3. qt5.git tester immediately adds comment I'll start testing your change in (~ some time estimate) 4. qt5.git tester later adds pass or fail comment, with a link to a build/test log. 3 could be omitted if that's perceived as too noisy. You could add multiple testers with different goals this way, and they'd operate independent from each other. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing QtWebkit from gerrit ( qt5.git)
Robin Burchell said: On Thu, Dec 8, 2011 at 12:20 AM, Rohan McGovern rohan.mcgov...@nokia.com wrote: Unfortunately the qtwebkit pointed at by qt5.git is outdated and known not to work. Given that webkit is developed upstream inside webkit.org, I'd second that there's no reason having it there, aside perhaps from CI, though AFAIK they have their own infrastructure for this. As qtwebkit adds hugely to cloning qt5 (unless you remember to disable it), as well as the frequent build problems for people new to Qt 5 etc, is there any real objection to it being removed? Who can make that decision (I guess Lars?), and who would handle doing that? Technically, approving and merging this change should do it: http://codereview.qt-project.org/11058 , and also changing the qtwebkit-examples-and-demos repository (which never receives commits anyway?) to use direct submit instead of staging with CI. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
Stephen Kelly said: On Wednesday, November 09, 2011 13:54:37 Thiago Macieira wrote: On Friday, 28 de October de 2011 12:38:38 lars.kn...@nokia.com wrote: We've been moving this lib quite a bit already. If we move it again, I'd prefer it would end up at it's final location. The move was done before we had the decision to keep QtCore independent of V8 and to separate the QJS* classes and the QML engine into it's own module. With the above decision it might make sense to move V8, the QJS* classes and the QML engine all into the same shared library. Kent Aaron, any thoughts? Since they don't seem to have an opinion, can we please move it to top-level inside qt5.git? I've just caught a bad commit in my tree that updates the commit link to v8 and I'm trying to fix it with an interactive rebase. Bump. This is a recurring problem with newcomers trying to build qtbase. They don't know to do the git submodule magic or use -no-v8, so the build fails. I think this can be easily mitigated by having qmake check if the sources exist, rather than simply assuming that they do. e.g. http://codereview.qt-project.org/10934 . ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to create new Qt modules or tools
Laszlo Papp said: 1) Build and software testing service Is there a build and software testing service provided for projects in the Qt Playground repositories ? I have not seen any mentionings about that so far. and it is an important question in my case, for instance. I have been using CDash [1] for projects under the KDE umbrella. It is possible as long as I use cmake as a build system in my project. I think such a build and software testing service along with the publishing of the build results would increase the QA of those playground projects. I know there are such QA services for final modules. I was just curious if those tools, providing the relevant services, are available to Qt Playground projects or not. If not, are there some other options ? It would be really nice if playground projects could get such an attention. I am not willing to propose it for all the projects there because I do not know the capacity, but at least for projects and maintainers there who are interested in this matter. Security is a potential issue for providing the same test resources used for the main Qt modules to be also used against playground modules. These test machines are Internet-connected[1], and arbitrary code can be set up to run on them; lowering the barrier for getting this arbitrary code onto the machines of course increases the security risk. http://my.cdash.org/ It would be interesting to know for example how Kitware handled this issue for the above, or if it was explicitly decided to accept the risk (which may well be a valid approach, given that the process includes a trusted maintainer signing off on the new playground project). [1] perhaps not forever - I'm describing the way things are and not necessarily the way they should be :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Missing ARM, MIPS, other mkspecs in qt5
Thiago Macieira said: On Wednesday, 30 de November de 2011 15.47.00, Rohan McGovern wrote: Hello, In Qt5, we no longer appear to have any mkspecs for cross-compiling for ARM or MIPS. They were tied up with qws, so they were removed when qws was removed. Is it intentional that we still don't have any, or has it just fallen out that way and we're free to add some generic ARM, MIPS mkspecs for testing purposes? mkspecs for cross-compilation are ill-suited, because the compiler name changes a lot. A better solution would be to make those configure-time options and simply use the standard mkspec for the platform. I guess that until such time as a proper build system is in place for Qt, we'll have to make do though. A linux-arm-gnueabi-g++ mkspec was added, which is identical to a linux-g++ mkspec except for the compiler commands. The next issue we hit in testing is that a standalone cross-compiler does not provide any GL API, which is nowadays required to compile Qt. We did not want to use some vendor-specific GL (or couldn't due to licensing), so we're now using a cross-compiled mesa (packaged at https://launchpad.net/~rohanpm/+archive/qtqa-cross ). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NOTE: Gerrit going down for quick fix deployment (13:30 CET)
marius.storm-ol...@nokia.com said: On 11/17/11 1:12 PM, ext marius.storm-ol...@nokia.com marius.storm-ol...@nokia.com wrote: Hi, Gerrit will go down at 13:30 CET today, for deployment of fixes for the following issues: https://bugreports.qt.nokia.com/browse/QTQAINFRA-167 https://bugreports.qt.nokia.com/browse/QTQAINFRA-270 https://bugreports.qt.nokia.com/browse/QTQAINFRA-335 https://bugreports.qt.nokia.com/browse/QTQAINFRA-347 https://bugreports.qt.nokia.com/browse/QTQAINFRA-350 https://bugreports.qt.nokia.com/browse/QTQAINFRA-352 It should only take a few minutes to deploy and restart the service, should nothing unexpected happen. I'll will send out a follow-up once the service is back up. Deployment was successful, thank you for your patience. Unfortunately the new version appears to have some quite annoying bug which is damaging the history of our repositories: https://bugreports.qt.nokia.com/browse/QTQAINFRA-389 If you have a look at http://qt.gitorious.org/qt/qtbase/commits/master for example you can see that all of today's changes look like they've been applied twice. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] configure qtbase on mac os
Chris Meyer said: I'm configuring qtbase (Mac OS 10.6.8, Xcode 4.2, and qtbase/master) using the following command: export QTDIR=/some/path/for/installation ./configure -prefix $QTDIR -opensource -no-sql-mysql -qt-libpng -qt-libjpeg -no-dbus -nomake examples -nomake demos After a while, I get an error that configure cannot determine big-endian or little-endian. Hmm, do you get anything useful if you add -verbose to configure? However, these options seem to be required only if I'm building with the -qpa option, which should default to off. Why do you think qpa should default to off? It doesn't, it defaults to on. It looks like the variable $PLATFORM_MAC is not being set properly. Is this something that needs to be specified on the command line or is the machinery for automatically setting $PLATFORM_MAC broken? PLATFORM_MAC shouldn't be set, because that indicates an old non-qpa carbon or cocoa build. qpa is the default and non-qpa paths are being eliminated. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QT_DEPRECATED_SINCE and QT_DISABLE_DEPRECATED_BEFORE
Thiago Macieira said: On Wednesday, 2 de November de 2011 10:53:40 bradley.hug...@nokia.com wrote: On 02 Nov, 2011, at 01:29 , ext Rohan McGovern wrote: I also noticed that Brad recently added the ability to pass through options like -Werror into configure [ http://codereview.qt-project.org/7487 ]. I intend for us to attempt using that in CI as soon as we have newer gcc available (= 4.6), which will be soon. Any opinions on exactly the appropriate -W* options would be appreciated :) I would love to see us fix all the -Woverloaded-virtual warnings… there are tons of them :( I'd like to enable -Werror by default if you use -developer-build. That way, everyone of us is on the same boat, modulo compiler version. The CI system doesn't (or didn't use to) build in developer mode, but if Rohan says it's a goal, I'm not going to say no :-) Nowadays it builds roughly 50% in developer mode and 50% not, as there was no other solution forthcoming to exercise all those autotests which need private symbols. Some Qt modules have very little test coverage in the non-developer configuration, unfortunately. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New circular buffer container for Qt5
Sean Harmer said: Hi, I would like to introduce a new generic container class to Qt, QCircularBuffer. This email is to see if there are any objections to doing so. This class is similar to QVector but it provides circular semantics. For example, appending to an already full circular buffer will overwrite the oldest item i.e. it forms a kind of LRU cache. The API is essentially a Qt'ified version of the boost::circular_buffer [1] API so hopefully people will find it simple to use. Hi, Any comments on how QCircularBuffer compares to the existing QContiguousCache[1] ? [1] http://doc.qt.nokia.com/4.7/qcontiguouscache.html ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
