Re: [Development] Copyright changes

[Rohan McGovern]

On Sat, Mar 2, 2013 at 3:34 PM, Laszlo Papp  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

[Rohan McGovern]

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

[Development] On the reliability of CI

[Rohan McGovern]

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.

>  [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.
>  [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 severa

[Development] Nominating Janne Anttila as Approver

[Rohan McGovern]

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

[Development] New mailing list, ci-reports

[Rohan McGovern]

Hi all,

Please be aware of this new Qt Project mailing list, ci-reports:

  http://lists.qt-project.org/mailman/listinfo/ci-reports

This list receives automated reports from the Qt Project CI system
pertaining to test run passes or failures (essentially the same
information posted to gerrit).

It also receives error reports and follow-up discussion when something
goes wrong with the CI system.
___
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

[Rohan McGovern]

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?

[Rohan McGovern]

Thiago Macieira said:
> On quarta-feira, 10 de outubro de 2012 15.01.56, Stephen Chu wrote:
> > The last commit in  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

[Rohan McGovern]

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] Code coverage statistics online

[Rohan McGovern]

Harri Porten said:
> Hi!
> 
> We started publishing code coverage results of Qt 5 unit test runs as 
> produced by our tool Squish Coco:
> 
>http://download.froglogic.com/public/qt5-squishcoco-report/ (results)
>
> http://download.froglogic.com/public/effectively-testing-qt5-using-squishcoco/
>  (setup and example)
> 
> >From that link you can browse to the coverage data of libraries, functions 
> and source files.
> 
> We chose a decision/coverage analysis method. In comparison to line 
> coverage this is a bit harder to grasp and gives different numbers but for 
> a developer it's the more useful. I plan to follow up with a study of a 
> small number of exemplaric cases accompanied with suggested patches to 
> tests and maybe code. And to make things easier to understand in the 
> mostly-static HTML output we'll also improve the coloring of instrumented 
> branches soon.
> 
> Provided that the cron job works the results will be updated daily. If 
> anyone has an idea how this could be integrated more tightly with the 
> automated Qt project test results please let us know. Caroline Chao was 
> already using a predecessor of the tool for the same purpose within 
> the Nokia build infrastructure btw.
> 
> Feedback of any kind is welcome.

Overall the coverage was less than I expected, so I started reading the
source files list starting from lowest coverage and found some surprising
results, e.g. qmimedata.cpp 0% coverage, qsettings.cpp nearly 0%
coverage although I know there are tests for these.

In the execution list at
http://download.froglogic.com/public/qt5-squishcoco-report/libQtCore.so.5.0.0.html
indeed it seems that tst_QSettings, tst_QMimeData are missing from the
list :(  I suppose there are others missing too. Any idea what might
have caused them to be excluded from the results?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] bool QProcess::waitForFinished() Race Condition?

[Rohan McGovern]

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

[Development] Upcoming CI disruptions

[Rohan McGovern]

In preparation for the transfer of remaining systems from Nokia to
Digia, various projects covered by the Qt CI will soon be migrated from
Nokia's Pulse infrastructure to a new Jenkins setup.

The migration will begin tomorrow. The first projects to be migrated
will be QA-related projects (dogfooding). Assuming no showstoppers
occur, the migration will continue next week.

In theory, there should be very few user-visible differences from the
migration.  Changes may be staged as usual.  However, please be aware of
a higher than normal risk of disruptions during this time.
___
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

[Rohan McGovern]

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?

[Rohan McGovern]

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] tools/configure with mingw build error

[Rohan McGovern]

Peter Kümmel said:
> On 28.08.2012 21:14, Peter Kümmel wrote:
> > On 28.08.2012 20:46, Peter Kümmel wrote:
> 
>  But also jom fails, I thought jom could also handle mingw makefiles?
> >>>
> >>> No, Jom only handles NMake makefiles, afaik.
> >>>
> >>
> >> Checked it again: I could build qt/4.8 with jom.
> >>
> >> So I would say the Makefiles in Qt5 are broken (at least for configure).
> >>
> >
> > Also the makefile for qmake doesn't work.
> >
> > In Qt 4.8 for qmake there are two makefiles for g++:
> > Makefile.win32-g++ and Makefile.win32-g++-sh
> >
> > In qtbase/qmake there is only Makefile.win32-g++.
> > The two files were merged:
> >   
> > https://qt.gitorious.org/qt/qtbase/commit/d9bf972e2b5f6bace5b7be350a70b4207e320692
> >
> > Seems nobody have used mingw/jom since 6 months.
> >
> 
> This could be all checked by CI, but it isn't.
> 
> Is there a list which configurations are checked by the CI?
> 

Yes, you can check the list from testresults.qt-project.org, e.g.
http://testresults.qt-project.org/ci/QtBase_master_Integration/latest-success/

MinGW used to be tested by CI, but the compiler frequently crashed
(internal compiler error), so it was removed - there are some links from
this task: https://bugreports.qt-project.org/browse/QTQAINFRA-549

> For instance CMake checks >30 Windows and >60 Linux/Unix configuration on a 
> daily basis (even jom)
> http://open.cdash.org/index.php?project=CMake
> 

Impressive for sure, but note it is not really fair to compare that with
Qt's CI, since Qt's needs to pass before code is allowed in (quality gate)
while most of the configurations in the above link apparently don't
(not a quality gate).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The containers in the "containers" branch

[Rohan McGovern]

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

[Rohan McGovern]

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

[Rohan McGovern]

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] Use static qt libraries

[Rohan McGovern]

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]

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

[Rohan McGovern]

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

[Rohan McGovern]

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] Notes from QtNetwork sessions

[Rohan McGovern]

shane.kea...@accenture.com said:
> 
> * Autotests
>   * Non-significant
>   * Not compiled

What is meant by "not compiled"?

>   * Dependency on the test server
>   * eg. QNetworkReply has too many tests they should be broken up
>   * Some tests should be recognised as possible to fail, unit tests should not
> fail. CI can be smarter if it knows which is which.
>   * Separate executables for each so they can have differing retry strategies.
> 

Breaking up tests with a long runtime into smaller test executables
helps in several ways ... it allows each subtest to be retried
individually if necessary, and may allow them to be run in parallel as well.
It's a good idea.

I saw some chat on IRC about, I think, grouping the tests into different
directories to classify their expected stability.  If you want to go
down that route then I think it would be better to introduce a new hint
to the CI system at http://qt-project.org/wiki/CI_Autotest_Metadata ,
rather than making it depend on the directory layout.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Code of conduct.

[Rohan McGovern]

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

[Rohan McGovern]

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  -sysroot 
>   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

[Rohan McGovern]

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

[Rohan McGovern]

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] More CI people?

[Rohan McGovern]

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] Qt 4.8 autotests need attention; over 100 insignificant tests!

[Rohan McGovern]

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] Becoming a Tier 1 platform and the CI System

[Rohan McGovern]

Molkentin Daniel (Nokia-MP/Berlin) said:
> 
> > 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 :(
> 
> 
> How likely/far away is it that we can switch from Pulse to Jenkins for CI? 
> Because in that case, we could federate CI builds.
> 

Nobody is working on it, so at the current rate of work, it is
infinitely far away :)

> Given that the actual logic should be shell/perl/python scripts, this should 
> be doable, right?
> 

The scripts which have the logic for testing are not at all Pulse
specific and can already be used successfully in Jenkins, or any other
decent CI tool.

The glue between gerrit and Pulse would have to be rewritten to support
Jenkins, but this is small (and that code is long overdue a complete
rewrite).

I don't think it matters much which one of these tools is used at that
layer, they're all pretty similar.
___
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

[Rohan McGovern]

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"  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

[Development] Qt 4.8 autotests need attention; over 100 insignificant tests!

[Rohan McGovern]

Hi all,

When Qt 4.8 was moved to gerrit, corners were cut to get it working with
the Qt 5 test infrastructure.  This included the disabling of many
autotests, ostensibly as a temporary measure.

Unfortunately this temporary situation has, to date, not been followed
up on, and we still have greater than 100 autotests effectively disabled
(marked as insignificant) in Qt 4.8's CI system.

These are the relevant tests, in need of attention.  Currently, _none_
of these tests are being used to block regressions:

  tests/auto/bic
  tests/auto/compilerwarnings
  tests/auto/declarative/examples
  tests/auto/declarative/qdeclarativeborderimage
  tests/auto/declarative/qdeclarativedebugjs
  tests/auto/declarative/qdeclarativeerror
  tests/auto/declarative/qdeclarativeimage
  tests/auto/declarative/qdeclarativetext
  tests/auto/declarative/qdeclarativexmlhttprequest
  tests/auto/declarative/qmlvisual
  tests/auto/exceptionsafety_objects
  tests/auto/guiapplauncher
  tests/auto/headers
  tests/auto/languagechange
  tests/auto/linguist/lupdate
  tests/auto/macgui
  tests/auto/macnativeevents
  tests/auto/mediaobject
  tests/auto/q3actiongroup
  tests/auto/q3process
  tests/auto/q3socket
  tests/auto/q3sqlcursor
  tests/auto/q3urloperator
  tests/auto/qaccessibility
  tests/auto/qapplication
  tests/auto/qaudioinput
  tests/auto/qclipboard
  tests/auto/qcolumnview
  tests/auto/qdbusmarshall
  tests/auto/qeventloop
  tests/auto/qfilesystemmodel
  tests/auto/qfilesystemwatcher
  tests/auto/qfile
  tests/auto/qfocusevent
  tests/auto/qfont
  tests/auto/qftp
  tests/auto/qgl
  tests/auto/qglthreads
  tests/auto/qgraphicsanchorlayout1
  tests/auto/qgraphicsanchorlayout
  tests/auto/qgraphicseffect
  tests/auto/qgraphicsitem
  tests/auto/qgraphicsproxywidget
  tests/auto/qgraphicsscene
  tests/auto/qgraphicstransform
  tests/auto/qgraphicsview
  tests/auto/qgraphicswidget
  tests/auto/qhostinfo
  tests/auto/qhttp
  tests/auto/qimagereader
  tests/auto/qinputcontext
  tests/auto/qinputdialog
  tests/auto/qitemdelegate
  tests/auto/qlibrary
  tests/auto/qlistwidget
  tests/auto/qlocale
  tests/auto/qlocalsocket
  tests/auto/qmacstyle
  tests/auto/qmdiarea
  tests/auto/qmdisubwindow
  tests/auto/qmenu
  tests/auto/qnetworkconfigurationmanager
  tests/auto/qnetworkconfiguration
  tests/auto/qnetworkreply
  tests/auto/qnetworksession
  tests/auto/qpainter
  tests/auto/qpauseanimation
  tests/auto/qpixmap
  tests/auto/qpluginloader
  tests/auto/qprinter
  tests/auto/qscriptcontext
  tests/auto/qscriptextensionplugin
  tests/auto/qscriptv8testsuite
  tests/auto/qscrollbar
  tests/auto/qsettings
  tests/auto/qsharedpointer_and_qwidget
  tests/auto/qsharedpointer
  tests/auto/qsocketnotifier
  tests/auto/qsocks5socketengine
  tests/auto/qsslsocket_onDemandCertificates_member
  tests/auto/qsslsocket_onDemandCertificates_static
  tests/auto/qsslsocket
  tests/auto/qstylesheetstyle
  tests/auto/qtableview
  tests/auto/qtcpserver
  tests/auto/qtcpsocket
  tests/auto/qtextlayout
  tests/auto/qtextscriptengine
  tests/auto/qtextstream
  tests/auto/qtimeline
  tests/auto/qtipc/qsharedmemory
  tests/auto/qtooltip
  tests/auto/qtreeview
  tests/auto/qudpsocket
  tests/auto/quuid
  tests/auto/qwebframe
  tests/auto/qwebpage
  tests/auto/qwidget
  tests/auto/qwidget_window
  tests/auto/qwizard
  tests/auto/selftests
  tests/auto/symbols
  tests/auto/xmlpatterns

( found by: git grep insignificant_test -- tests/auto )

I need your help to improve the situation.  For anyone interested in
ensuring the quality of Qt 4.8, this is a great way to help out.
Nokia's own QA staff is almost exclusively working on Qt 5 or related
projects and we won't be able to fix this ourselves.

The goal is to remove CONFIG+=insignificant_test from as many of these
autotests as possible.

How you can help:

  - check the current status of these tests for each platform.  This can
always be ascertained from these links:

  
http://testresults.qt-project.org/ci/Qt_4.8_Integration/latest-success/linux-g++-32_Ubuntu_10.04_x86/log.txt.gz
  
http://testresults.qt-project.org/ci/Qt_4.8_Integration/latest-success/linux-g++_developer-build_qtnamespace_qtlibinfix_Ubuntu_11.10_x64/log.txt.gz
  
http://testresults.qt-project.org/ci/Qt_4.8_Integration/latest-success/macx-g++_OSX_10.6/log.txt.gz
  
http://testresults.qt-project.org/ci/Qt_4.8_Integration/latest-success/macx-g++_OSX_10.7/log.txt.gz
  
http://testresults.qt-project.org/ci/Qt_4.8_Integration/latest-success/macx-g++_developer-build_OSX_10.7/log.txt.gz
  
http://testresults.qt-project.org/ci/Qt_4.8_Integration/latest-success/qws_linux-x86-g++/log.txt.gz
  
http://testresults.qt-project.org/ci/Qt_4.8_Integration/latest-success/win32-msvc2010_Windows_7/log.txt.gz
  
http://testresults.qt-project.org/ci/Qt_4.8_Integration/latest-success/win32-msvc2010_developer-build_Windows_7/log.txt.gz

  - if the test is already passing on some platforms, you can amend the
insignificant_test condition to apply only to the platforms

Re: [Development] Quick2 and Directx11 backend (Angle)

[Rohan McGovern]

Friedemann Kleint said:
> Hi,
> 
> after some polishing, then change has been merged as 
> e7f1106edb1ac37d92d7851c44cd8d99f68eaaf4 .
> I have added some build instructions to 
> http://qt-project.org/wiki/Building_Qt_5_from_Git for everyone to try out.
> 
> We might decide later to add the library to our 3rd-Party folder.
> 

Since our virtual machines in the Qt Project CI don't have any kind of
hardware GL, all GL tests on Windows are basically useless there.

I am hoping ANGLE might help us in this regard.  If anyone has some
valuable comment in that respect, please feel free to add to
https://bugreports.qt-project.org/browse/QTQAINFRA-525

That use-case would also be helped a lot by having ANGLE under
src/3rdparty :)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Binary incompatible changes to Qt 4.8

[Rohan McGovern]

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

[Rohan McGovern]

Loaden said:
> >
> > Generating Code...
> >  link /LIBPATH:"d:\qpSOFT\Projects\BuildQt5-x64\qtbase\lib"
> > /LIBPATH:"d:\qpSOFT\Projects\BuildQt5-x64\qtbase\lib"
> > /LIBPATH:"d:\qpSOFT\Projects\BuildQt5-x64\qtbase\lib" /NOLOGO /DYNAMICBASE
> > /NXCOMPAT /DEBUG /DLL /MANIFEST
> > /MANIFESTFILE:"debug\declarative_locationd.intermediate.manifest"
> > /OUT:d:\qpSOFT\Projects\BuildQt5-x64\qtbase\imports\QtLocation\declarative_locationd.dll
> > @C:\Users\loaden\AppData\Local\Temp\nmAC70.tmp
> > poly2tri.lib(cdt.obj) : error LNK2038: mismatch detected for
> > '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in
> > qdeclarativeposition.obj
> > poly2tri.lib(sweep_context.obj) : error LNK2038: mismatch detected for
> > '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in
> > qdeclarativeposition.obj
> > poly2tri.lib(sweep.obj) : error LNK2038: mismatch detected for
> > '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in
> > qdeclarativeposition.obj
> > poly2tri.lib(advancing_front.obj) : error LNK2038: mismatch detected for
> > '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in
> > qdeclarativeposition.obj
> > poly2tri.lib(shapes.obj) : error LNK2038: mismatch detected for
> > '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in
> > qdeclarativeposition.obj
> >Creating library
> > d:\qpSOFT\Projects\BuildQt5-x64\qtbase\imports\QtLocation\declarative_locationd.lib
> > and object
> > d:\qpSOFT\Projects\BuildQt5-x64\qtbase\imports\QtLocation\declarative_locationd.exp
> > LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other
> > libs; use /NODEFAULTLIB:library
> > d:\qpSOFT\Projects\BuildQt5-x64\qtbase\imports\QtLocation\declarative_locationd.dll
> > : fatal error LNK1319: 5 mismatches detected
> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > Studio 10.0\VC\Bin\amd64\link.EXE"' : return code '0x527'
> > Stop.
> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > Studio 10.0\VC\Bin\amd64\nmake.exe"' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> >
> > Build broke after re-install Windows SDK 7.1.
> Any comments?

Hi Loaden,

You seem to be getting a link error from mixing debug and release
versions of libraries.

I believe there is an error in
qtlocation/src/imports/location/location.pro, these two lines:

  LIBS += -L../../3rdparty/poly2tri -lpoly2tri
  win32:LIBS += -L../../3rdparty/poly2tri/release 
-L../../3rdparty/poly2tri/debug

Unless I've missed something, there's nothing here which ensures the
debug version of declarative_location is linked with the debug version
of the poly2tri static library.
___
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

[Rohan McGovern]

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] Binary incompatible changes to Qt 4.8

[Rohan McGovern]

Turunen Tuukka said:
> 
> On 24.5.2012 15.32, "Thiago Macieira"  wrote:
> 
> >On quinta-feira, 24 de maio de 2012 12.13.31, Yan Shapochnik wrote:
> >> Since you are back porting this change to 4.8, I would also like to
> >>make a
> >> suggestion and include Mac OS X 10.8 Mountain Lion support in the same
> >> manner.
> >
> >Yes, makes sense.
> 
> 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?

If so, I think that would be feasible for Ubuntu 12.04 before Qt 4.8.3,
but not the others.
___
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

[Rohan McGovern]

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 2>&1
>  - perl build 1>build.log 2>&1
> 

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] Bugreports for Playground projects

[Rohan McGovern]

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] qtphonon's status.

[Rohan McGovern]

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] Cross build failed of unsupported/win32-g++-cross mkspecs

[Rohan McGovern]

k blammo said:
> >> "+ /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".
> >
> 
> Strange, that's not in my configure log.

It's from the configure in qt5.git.
So, if you've been running qtbase's configure directly, that might
explain the difference :)
___
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

[Rohan McGovern]

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] Build issue with configure -developer-build for qtbase?

[Rohan McGovern]

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] How to submit an approved patch?

[Rohan McGovern]

Carl Schumann said:
> Qt developer community,
> 
> I am a first timer at this process, but have now managed to get a change 
> approved:
> https://codereview.qt-project.org/26041
> According to http://wiki.qt-project.org/Qt_Contribution_Guidelines I 
> should now submit my patch.  I am looking for more detail on how to 
> submit a patch please.  E.g., How do I tell if the branch and/or 
> repository to which I am submitting has a CI system please?

You can check to see if the project and branch you are submitting to is
covered at http://testresults.qt-project.org/ci/ , I've updated the wiki
to mention this.
___
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

[Rohan McGovern]

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" -I"tmp" -I"animations" -I"debug" 
> -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

[Rohan McGovern]

Girish Ramakrishnan said:
> Hi,
> 
> On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan
>  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

[Rohan McGovern]

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

Re: [Development] [CI] reverse dependency testing

[Rohan McGovern]

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

[Development] [CI] reverse dependency testing

[Rohan McGovern]

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] Can't build docs anymore!

[Rohan McGovern]

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] Can't build docs anymore!

[Rohan McGovern]

Loaden said:
> NMAKE : fatal error U1095: expanded command line ...  too long
> Any comments?

You could possibly work around this by putting your sources in a shorter
path, e.g. D:\Qt5.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Towards a Qt 5 beta

[Rohan McGovern]

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 2>&1 | 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

[Rohan McGovern]

marius.storm-ol...@nokia.com said:
> On 04/11/2012 07:49 AM, ext 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 ': insignificant ' 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] [Releasing] Qt 5.0 alpha released

[Rohan McGovern]

simo.f...@nokia.com said:
> Moi,
> I can't provide you an easy way but I can show you a way to get the alpha
> out of git (see below). But yes, it is true that there isn't any tag in
> git but I hope we will fix that in future releases.

Hmm, it's not too late to fix it for _this_ release though.
There's nothing stopping us from preparing and pushing 5.0.0-alpha tags
now?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Compiling Qt5 Alpha on Linux fails

[Rohan McGovern]

marius.storm-ol...@nokia.com said:
> Try following the instructions here
> http://qt-project.org/wiki/Qt-5-Alpha-building-instructions
> 
> Qt should not be configured in such a way that it needs to be installed. 
> That's not a supported build configuration for the alpha.
> Only in-source non-install builds for alpha.
> 

If we only support in-source non-install builds for now, what was the
reason for adding that "build" script?
___
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

[Rohan McGovern]

Knoll Lars (Nokia-MP/Oslo) said:
> On 3/19/12 2:11 AM, "ext Rohan McGovern"  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

[Rohan McGovern]

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
's CI if qtdeclarative's sync.profile does not contain
"qtbase => refs/heads/".

> 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] Nominating Kurt Korbatits for approver

[Rohan McGovern]

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] cast ... increases required alignment of target type [-Werror=cast-align]

[Rohan McGovern]

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] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1

[Rohan McGovern]

Richard Moore said:
> On 12 March 2012 17:56,   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 
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]

[Rohan McGovern]

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 
> >   410: Q_INLINE_TEMPLATE void QList::node_destruct(Node *from, Node *to)
> >   411: {
> >   412:if (QTypeInfo::isLarge || QTypeInfo::isStatic)
> >   413:while(from != to) --to, delete reinterpret_cast(to->v);
> >   414:else if (QTypeInfo::isComplex)
> >   415:while (from != to) --to, reinterpret_cast(to)->~T();
> >   416: }
> 
> > src/corelib/tools/qlist.h:415:28: error: cast from
> > ‘QList::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]

[Rohan McGovern]

Does anyone have a suggestion on how to fix this warning?

This code in qlist.h:

  409: template 
  410: Q_INLINE_TEMPLATE void QList::node_destruct(Node *from, Node *to)
  411: {
  412:if (QTypeInfo::isLarge || QTypeInfo::isStatic)
  413:while(from != to) --to, delete reinterpret_cast(to->v);
  414:else if (QTypeInfo::isComplex)
  415:while (from != to) --to, reinterpret_cast(to)->~T();
  416: }

...when compiled for ARM, causes this warning (or error with -Werror):

  src/corelib/tools/qlist.h: In member function ‘void 
QList::node_destruct(QList::Node*, QList::Node*) [with T = QVariant]’:
  src/corelib/tools/qlist.h:738:5:   instantiated from ‘void 
QList::dealloc(QListData::Data*) [with T = QVariant]’
  src/corelib/tools/qlist.h:714:9:   instantiated from ‘QList::~QList() 
[with T = QVariant]’
  src/corelib/statemachine/qstatemachine.h:81:59:   instantiated from here
  src/corelib/tools/qlist.h:415:28: error: cast from ‘QList::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] Mirror of Qt on github?

[Rohan McGovern]

Holger Hans Peter Freyther said:
> Hi,
> 
> my jenkins build server is having a lot of build issues due of gitorious.org
> not being able to serve via the git protocol (git-daemon). One of the latest
> failures can be seen here[1]. Should we try to have Gerrit replicate to
> github.com or any other more reliable git hosting provider?
> 

It may be a good idea to set up your own local (polling) git mirror and point
your jenkins towards that.  In our experience from when v8 was hosted on
github.com, that service also has reliability problems occasionally.
___
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]

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] Qt Project CI having a bad day

[Rohan McGovern]

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] qtwebkit-examples-and-demos.patch

[Rohan McGovern]

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] Tests, Shadow-Build and Cross-Compilation

[Rohan McGovern]

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] Use make before you push and stage

[Rohan McGovern]

Giuseppe D'Angelo said:
> On 30 January 2012 03:51, Rohan McGovern  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] Suggestion for new CI: "early warning" for qt5.git

[Rohan McGovern]

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] Suggestion for new CI: "early warning" for qt5.git

[Rohan McGovern]

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] Use make before you push and stage

[Rohan McGovern]

Stephen Kelly said:
> I wonder if it's possible for the CI system to maintain and clone 
> a working master build which patches could be applied to and build 
> incrementally? (an un-clean build)
> 

Andreas said:
> How about investigating incremental builds? Could reduce compile time
> to just a few minutes per patch. We do that where I work, with hundreds
> of changes done to the repo every day, and every single patch is
> compiletested. Tests are also run per change, but we only run fast
> tests per change; slow tests are run in a separate cycle (on a best
> effort basis).
>
> The occasional breakage happens whenever changes are made to build
> files, like Makefiles or pro files, typically when moving code around.
> But it's rare and manageable, as long as it's possible to force a full
> rebuild on demand.

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.

For example, if you make a change which causes some library or header to
be removed/renamed, and you forget to update all consumers of that
library/header, it can easily go unnoticed, because the old
library/header still exists in the build tree until you do a clean
build.

Another example is failing to declare the dependencies between projects,
which would typically be discovered by a clean build with high -j, but
missed in incremental builds (because the dependencies are probably
still there from the last build).

I can't comment exactly how rare or not that would be for Qt.
I guess it would happen more often during the most critical times and
cause frustration when everyone is trying to get their refactoring
integrated before some freeze.  Anyway, I am not really interested in
hitting the "do a clean build" button or attempting to
determine/communicate the heuristics for deciding to do that.

I would prefer us to move towards the state where, if the CI system
posts a failure report onto your change, then there is a very high
chance the failure is actually caused by your change.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use make before you push and stage

[Rohan McGovern]

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] Tests, Shadow-Build and Cross-Compilation

[Rohan McGovern]

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] Instructions how to set up cherry-picking between Qt5 and Qt4 repositories?

[Rohan McGovern]

ext-sami.1.rosend...@nokia.com said:
> 
> Hi
> 
> I am backporting fixes I have pushed to Qt5 to Qt4.8 now that 4.8 is 
> available in gerrit. I got comments to my Qt4.8 patches that I should 
> preferably cherry-pick the Qt5 commits to Qt4. I do not know how to set up my 
> environment to enable the cherry-picking because of the separate Qt5 and 
> Qt4.x repositories and their different directory structures.
> 
> I found the tool qtrepotools/bin/git-qt-cherry-pick in Qt5 repository, but 
> have not been able to figure out how to use it or how to set up the 
> repositories to enable its use. Lacking the cherry-picking capability I have 
> moved commits between Qt5 and 4.x using git format-patch & apply and have 
> edited the paths in the patches to match the target repo.
> 
> Any help or instructions for setting up cherry-picking would be much 
> appreciated.
> 
> 
> 
> Was able to figure something out:
> - git-qt-cherry-pick seems to prefer that the Qt4.x and Qt5 repository 
> directories are siblings in the same directory and the Qt5 path (looking from 
> the Qt4.x repository path) is ../qt5

It seems if your setup doesn't satisfy this, you can still make it work
with the "-p" option.

> - The  in the script usage means the base name of a Qt5 subrepository 
> (e.g. 'qtbase')
> 
> Alas, the script still fails:
> $ ../qt5/qtrepotools/bin/git-qt-cherry-pick -l qtbase 
> b851c764a61c0de781ef3447230a0a6a3f4a0ed9
> Porting from qt5/qtbase to qt
> Other path is ../qt5/qtbase
> Applying: Fix stack overwrite in QDBusDemarshaller
> fatal: sha1 information is lacking or useless 
> (tests/auto/dbus/qdbusmarshall/tst_qdbusmarshall.cpp).
> Repository lacks necessary blobs to fall back on 3-way merge.
> Cannot fall back to three-way merge.
> Patch failed at 0001 Fix stack overwrite in QDBusDemarshaller
> When you have resolved this problem run "git am --resolved".
> If you would prefer to skip this patch, instead run "git am --skip".
> To restore the original branch and stop patching run "git am --abort".
> Aborting at b851c764a61c0de781ef3447230a0a6a3f4a0ed9
> $

I was able to get your change as far as a "normal" conflict by the
following:

  cd ~/build/qt/4.8

  # copy all qt5 qtbase objects into qt 4.8
  git fetch -v ~/build/qt/qt5/qtbase 'refs/heads/*:refs/qt5-qtbase/*'

  # do the cherry-pick
  ~/build/qt/qt5/qtrepotools/bin/git-qt-cherry-pick -l qtbase -p 
~/build/qt/qt5/qtbase b851c764a61c0de781ef3447230a0a6a3f4a0ed9
  Porting from qt5/qtbase to qt
  Other path is /home/rmcgover/build/qt/qt5/qtbase
  Applying: Fix stack overwrite in QDBusDemarshaller
  Using index info to reconstruct a base tree...
  Falling back to patching base and 3-way merge...
  Renaming tests/auto/dbus/qdbusmarshall/tst_qdbusmarshall.cpp => 
tests/auto/qdbusmarshall/tst_qdbusmarshall.cpp
  Auto-merging tests/auto/qdbusmarshall/tst_qdbusmarshall.cpp
  CONFLICT (rename/modify): Merge conflict in 
tests/auto/qdbusmarshall/tst_qdbusmarshall.cpp
  Failed to merge in the changes.
  Patch failed at 0001 Fix stack overwrite in QDBusDemarshaller
  When you have resolved this problem run "git am -3 --resolved".
  If you would prefer to skip this patch, instead run "git am -3 --skip".
  To restore the original branch and stop patching run "git am -3 --abort".
  Aborting at b851c764a61c0de781ef3447230a0a6a3f4a0ed9

After this point you would need to resolve the conflict as usual.
The important thing is that you can see from the above that git was able
to follow the rename of tst_qdbusmarshall.cpp (therefore reducing
the amount of work you need to do manually to resolve conflicts).

> 
> I am assuming that the message "Repository lacks necessary blobs to fall back 
> on 3-way merge." may be related to the note "it's strongly recommended to 
> have linked object stores between the repositories to enable 3-way merges." 
> in this announcement about qt-cherry-pick I was able to find: 
> http://lists.qt-project.org/pipermail/development/2011-November/000483.html.
> 
> I don't know how to set up "linked object stores between the repositories". I 
> did set up the Git Grafts as instructed in the Qt5 README, but that did not 
> help with the git-qt-cherry-pick.

There are many ways to set up linked object stores, some of them
dangerous if you are not a git "power user".  What I did above is to
copy the objects from one repo to another rather than linking them.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Compiling Qt5 on Ubuntu Oneiric

[Rohan McGovern]

Kate Alhola said:
> Has anyone succeeded to compile current git snapshot with Ubuntu oneiric ?

Yes - but always without webkit.
This also came up in thread

  [Development] Trying to setup environment to contribute. Error building webkit
  http://www.mail-archive.com/development@qt-project.org/msg00691.html

> I have tried ./configure -prefix /home/kate/qt5/qt5/qtbase -opensource
> -confirm-license -nomake tests -no-webkit
> but that does not help, it still compiles jscore.

Most of the -no- configure arguments, where  comes
from a git module other than qtbase, do not work correctly in Qt 5.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Removing QtWebkit from gerrit (& qt5.git)

[Rohan McGovern]

Robin Burchell said:
> On Thu, Dec 8, 2011 at 12:20 AM, Rohan McGovern
>  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] How to create new Qt modules or tools

[Rohan McGovern]

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] V8's location

[Rohan McGovern]

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] Trying to setup environment to contribute. Error building webkit

[Rohan McGovern]

Jordi Pujol said:
> Hi all,
> 
> I've been trying to set up a personal clone of qt5 to start contributing
> as explained in wiki page.
> 
> http://developer.qt.nokia.com/wiki/Building_Qt_5_from_Git
> 
> I'm in gerrit, I've been successful to get the source initialized the
> repositories, configured & started to build as explained. Everithing
> gone fine.
> 
> But I'm stuck building qtwebkit. It's a very simple error, as you can
> see in the log, JSInspectorFrontendHostCustom.cpp includes QAction &
> QMenu  and both headers must be found in 
> /qt5/qtbase/include/QtWidgets, but the include line does not appear
> anywhere at compile time.
> 
> Anyway, .../qt5/qtbase/include/QtGui is there ( QT += gui must be set
> somewhere ), so something is wrong, but I cannot find what.
> 
> Perhaps nobody tried to work "as is" and I must pull latest version of
> webkit submodule ?
> 

Hi,

Unfortunately the qtwebkit pointed at by qt5.git is outdated and known
not to work.  Maybe it makes sense to remove it.  (IMHO qtwebkit there
is not making sense since it is more of a "project which uses Qt" and
not "part of the Qt Project").

For now, the easiest way for you to proceed would be to pass -no-webkit
to init-repository, or `rm -rf qtwebkit' if you already have it.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Missing ARM, MIPS, other mkspecs in qt5

[Rohan McGovern]

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

[Development] Public Qt5 CI results available

[Rohan McGovern]

Hello,

We've been able to move forward with publishing logs from
the Qt Continuous Integration system, which (prior to now)
have only been visible from within Nokia.

The CI logs are available at:

  http://testresults.qt-project.org/

For users of codereview.qt-project.org, any new test result links
posted onto your changes should now point to this host.

Please report any problems on http://bugreports.qt.nokia.com/ , project
QTQAINFRA, component "Test results".
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Missing ARM, MIPS, other mkspecs in qt5

[Rohan McGovern]

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?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt5-feedback] 3rdpart platform plugins, tests and CI

[Rohan McGovern]

Holger Hans Peter Freyther said:
> On 11/25/2011 02:40 PM, Holger Hans Peter Freyther wrote:
> > On 10/31/2011 11:30 PM, Sergio Ahumada Navea wrote:
> > 
> >> 2) Build -> Execute Shell
> >> Command (without the #):
> >># git clean -dqffx
> 
> 
> > I finally had a little time and my question would be.. What should I set
> > qtgitreadonly to? How long does it take until a change pops up on gitorious?
> 
> hi again,
> 
> one more thing. it is a bit painful (both on time and bandwidth) to always
> clone qtbase, qtwebkit... I assume you don't suffer too much because you have
> local mirrors in Oslo/Brisbane. How difficult will it be to attempt to update
> the repository (instead of failing) and only to rm -rf it in case the git
> fetch fails?

The mirrors help, but we also use a transparent git wrapper script,
so that the result of clones/fetches/etc is automatically cached.
However this script is not public and is quite buggy.
I would rather move to doing this explicitly, e.g. by using the
--alternates option to Qt5's init-repository.
https://bugreports.qt.nokia.com/browse/QTQAINFRA-126

Alternatively, if someone knows of a publicly available and good quality
caching wrapper or similar for git, please speak up :)

It would be fine too, and not very difficult, to update/clean the repos
if they already exist, rather than starting clean every time.

Holger, have you considered starting to work on these changes?
The vast majority of the "users" of these scripts (i.e. the people
submitting changes into Qt - indirect users) will not benefit at all,
so you cannot expect high prioritization from us.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt5-feedback] 3rdpart platform plugins, tests and CI

[Rohan McGovern]

Holger Hans Peter Freyther said:
> On 11/03/2011 07:06 PM, lars.kn...@nokia.com wrote:
> 
> > Yes, I agree that it'd be nice to avoid the recompile in that case.
> > However, this is the best way to be really certain your module works
> > against whatever it depends upon. It's not a huge issue on a decent
> > machine, at least if the dependent modules only compile the libraries and
> > don't run the tests as well (that is unless you're webkit or depend on
> > webkitŠ)
> 
> Hi,
> 
> I accept the current status I just want to give some feedback after today’s
> journey. Maybe we can learn something from that.
> 
> I am currently working on running Qt5 with the DirectFB plugin on MIPS. This
> means that I will compile on a fast machine, want to do make INSTALLROOT=/nfs
> install and then run it on my target machine. This has worked for qtbase
> itself but is failing miserably when I extended this to qtdeclarative.
> 
> Install:
> make INSTALLROOT=tmp install is used by Distributions to build packages,
> developers for deploying for a target. I hope we agree that this is a common
> usecase. To me it appears that because we have the testscript that creates one
> big source directory we don't test make install until we are before a release.
> I would encourage to include make install in the test (don't mind building
> everything, but also test deploying and testing the result of the deployment).
> See below for some details.

In fact deployment for this configuration (shadow build and make
install) is already underway.  It is in place and working for qtbase
already; for modules building on top of qtbase, bugs like
http://codereview.qt-project.org/9466 were uncovered and need to be fixed
first, and a bit of tweaking to the test script seems necessary.  But I
think we are talking somewhere between days and a couple of weeks before a
basic test for this is in place for all the modules.

This basic test at first is merely along the lines of `make install
gives a 0 exit code', but eventually we'd do some "testing the result of
the deployment" too.
___
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)

[Rohan McGovern]

marius.storm-ol...@nokia.com said:
> On 11/17/11 1:12 PM, "ext 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

[Rohan McGovern]

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] qtsystems doesn't compile - mtcore mandatory dependency

[Rohan McGovern]

Thiago Macieira said:
> On Wednesday, 2 de November de 2011 19:01:21 Aaron McCarthy wrote:
> > Hi,
> > 
> > On Wed, 2 Nov 2011 06:47:08 pm ext Thiago Macieira wrote:
> > > PS: are the unit tests outside qtbase ever compiled? The qtxmlpatterns
> > > ones
> > > don't build for me.
> > 
> > This depends on how you configure and build.  If the forwarding .qmake.cache
> > files in the Qt modules are not created or overwritten the modules will not
> > build anything but src.  This is because the QT_BUILD_PARTS qmake variable
> > from qtbase's .qmake.cache is not available.  The solution is to ensure
> > that QT_BUILD_PARTS="libs examples tests" is set in modules.
> 
> Hi Aaron
> 
> Sorry, that's not what I meant. The built is attempted, but fails:
> 
> /home/thiago/src/qt/qt5/qtxmlpatterns/tests/auto/xmlpatternssdk/ErrorItem.cpp:46:30:
>  
> fatal error: qreportcontext_p.h: No such file or directory
> 

The xmlpatterns tests are compiled and run in CI.

tests/auto/xmlpatterns.pri is supposed to pull in the directory
containing qreportcontext_p.h into INCLUDEPATH:

  XMLPATTERNS_SOURCES = $$QT.xmlpatterns.sources
  INCLUDEPATH += \
 (...)
 $$XMLPATTERNS_SOURCES/environment \

...so I am guessing that QT.xmlpatterns.sources is set in CI but not set
in your configuration (does your makefile contain nonsense like
"-I/environment" ?

The fix you mentioned should be made regardless.
___
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

[Rohan McGovern]

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] [Qt5-feedback] 3rdpart platform plugins, tests and CI

[Rohan McGovern]

Holger Hans Peter Freyther said:
> 
> >> how difficult will it be to only checkout/update/build qtbase and not 
> >> _all_ of
> >> Qt? Is this something that is planned?
> > 
> > That is already the way it works - as Shane Kearns pointed out in a
> > followup mail.  For testing qtbase, you get qt5, qtbase and v8.
> > For testing another gitmodule, you get just that gitmodule, plus the
> > gitmodules it depends on, plus qt5.
> 
> Sorry to be stubborn here. We try to have modules in Qt (in contrast to the
> monolithic qt as of the past), e.g. I could provide a 'Qt Monkey WebPage
> Scraper' module that is based on WebKit. Why would I want to build QtWebKit
> whenever I change something in my module? Do I miss the point?

No apologies necessary :)

If your module depends on QtWebKit, then you need some compiled QtWebKit
on your system.  Since nobody provides any recent Qt5 binaries at the
moment, the simplest way for you (and for our CI) to get that is to compile
it.

Reusing binaries from earlier builds would be great, but it makes the
test scripts more complex.  Currently I see it as an optimization, lower
priority than a lot of other pending work.  As mentioned on IRC, sure
we would accept patches into the test scripts which enable this way of
working.

> 
> So my question is. What prevents us from doing this:
> 
> Track QtBase-> build QtBase (as unpacked by the CI system)
> Track QtWebKit  -> build QtWebKit (as unpacked by the CI system)
> Track QtDeclarative -> build QtDeclarative (as unpacked by the CI system)
> 

Just as described above - if you build qtdeclarative, you need the
things which qtdeclarative depends on, and the most pragmatic way to get
those at the moment is to build them yourself.

> (no qt5 submodule involved, just plain git repository)
> 

Avoiding the usage of qt5.git requires a bit more work; qt.pro in that
repository is currently treated as the canonical source of information used
to determine the order in which modules need to be built.  Implementing
another way to build the dependency tree (which I don't believe would be
particularly difficult) would remove the need to use qt5.git.
___
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

[Rohan McGovern]

Thiago Macieira said:
> On Tuesday, 1 de November de 2011 10:55:49 Frans Klaver wrote:
> > On Tue, Nov 1, 2011 at 10:43 AM, Thiago Macieira  wrote:
> > > One more thing: QT_DEPRECATED expands to empty during the Qt build.
> > > 
> > > Should we enable QT_DEPRECATED_WARNINGS?
> > 
> > FWIW, my personal experience is that build warnings are noticed before
> > documentation changes. I always feel a deprecation warning during the
> > build is more likely to push people to move to the new API than just
> > changing the documentation -- a lot of people like warning-free
> > builds.
> > 
> > So I'd say that would be a yes.
> 
> I'd also like to work on enabling -Werror, but usually deprecation warnings 
> cannot be avoided, so I'll add also a Wno-error-deprecated.
> 

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 :)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtsystems doesn't compile - mtcore mandatory dependency

[Rohan McGovern]

Robin Burchell said:
> 2011/11/1 Thiago Macieira :
> > I cannot find this mandatory dependency. If it's open, can someone share the
> > link to where it can be found? If it's not open, please disable this
> > functionality.
> 
> I guess this might be a consequence of qtjsondb becoming available:
> 
> !contains(QT_CONFIG, jsondb): {
> PRIVATE_HEADERS += qscreensaver_linux_p.h
> SOURCES += qscreensaver_linux.cpp
> 
> DEFINES += QT_NO_JSONDB
> } else {
> PRIVATE_HEADERS += qjsondbwrapper_p.h \
>qscreensaver_jsondb_p.h
> 
> SOURCES += qjsondbwrapper.cpp \
>qscreensaver_jsondb.cpp
> 
> QT += jsondb
> PKGCONFIG += mtcore
> LIBS += -L$$[QT_INSTALL_PREFIX]/opt/mt/lib -lmtcore
> -Wl,-rpath,$$[QT_INSTALL_PREFIX]/opt/mt/lib
> }
> 
> Whoever maintains this, you should probably change that contains()
> conditional to also check packagesExist(mtcore).

Incidentally it's rather dangerous to do this kind of

  contains(QT_CONFIG,some_module):QT+=some_module

...behavior nowadays.  In Qt4, QT_CONFIG would be decided at configure
time, but in Qt5 it can be changed when you qmake additional modules.

In other words, if you test contains(QT_CONFIG,some_module) in your Qt5
module, you've made your build behavior implicitly depend on the order in
which the user happened to run `qmake' over the qt5 modules, which is
largely undefined.  e.g. if you are doing a `make -j20' in qt5.git, the
qmakes are also parallelized, and your result might flipflop between
builds.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt5-feedback] 3rdpart platform plugins, tests and CI

[Rohan McGovern]

Holger Hans Peter Freyther said:
> On 10/31/2011 11:30 PM, Sergio Ahumada Navea wrote:
> 
> > 1) Source Code Management -> Git
> > URL of repository: git://gitorious.org/qt/qtbase.git
> > Branch Specifier : master
> 
> 
> > Finally, you can see my build log: http://pastebin.com/iNVph7DP . This 
> > is almost the same that the CI system is doing right now.
> 
> Hi,
> 
> how difficult will it be to only checkout/update/build qtbase and not _all_ of
> Qt? Is this something that is planned?

That is already the way it works - as Shane Kearns pointed out in a
followup mail.  For testing qtbase, you get qt5, qtbase and v8.
For testing another gitmodule, you get just that gitmodule, plus the
gitmodules it depends on, plus qt5.

> E.g. with the creation of separate
> modules declarative/webkit probably should not always require the latest
> version of qtbase.

Currently, each gitmodule has a top-level sync.profile which specifies
the other repositories to be checked out for the test, along with their
SHA1.  Most of them are explicitly opting in to refs/heads/master (or
refs/heads/qml2 for qtquick3d) as it was decided a while back that the
goal should be to have the tip of all modules working together.  So,
yes, although the latest qtdeclarative may not require the latest
qtbase, it's an explicit choice (controllable by the module maintainer)
to test it this way at the moment.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt5-feedback] 3rdpart platform plugins, tests and CI

[Rohan McGovern]

Holger Hans Peter Freyther said:
> On 10/24/2011 04:21 PM, Holger Hans Peter Freyther wrote:
> > On 10/24/2011 04:01 AM, Rohan McGovern wrote:
> 
> Hi again,
> 
> the response I am responding to ended up in moderation, I am now properly
> subscribed (in contrast of using gmane.org). Just to recap, I have not
> asked/intended to just switch off pulse and not work until a new public system
> is in place. The problem for me is, I don't know how pulse works, so building
> a 'compatible' system is difficult.
> 
> I went ahead and setup a public jenkins on a shiny new server at hetzner,
> right now it is just tracking changes for Qtbase[1] (ipv4/ipv6), Jenkins has
> some Gerrit integration out-of-the-box but I am not sure how it relates to
> what you have with pulse.
> 
> I am not sure which config you have with Pulse. In Jenkins there is the
> concept of a 'Job' (e.g. build a project in a specific config), what I am not
> sure how to configure is to have the same Job be executed for (ARM, MIPS, X86,
> AMD64..). How is this done with Pulse? Is there a single 'Job' or one job for
> each target platform?

It sounds like the Jenkins concept of "job" and the Pulse concept of
"stage" are similar.  If so, this means that you should almost be
able to use the qtqa/testconfig.git repo out of the box to issue the
build commands.

For example, setting up a "job" which runs

  git clone git://gitorious.org/qtqa/testconfig.git _testconfig
  _testconfig/test.pl --project "QtBase master Integration" \
--stage "linux-g++-32 Ubuntu 10.04 x86"

...may already work, or be close enough to working that it gives some
valuable hints.

I believe Sergio may already have experimented with using the above
scripts in a Jenkins setup.  sahumada on IRC, if you need to contact
someone who understands those scripts and is likely to be awake during
Europe hours :)

> Is the EWS provided by the Pulse system as well?

No, Pulse isn't really well suited for this.  My guess is that Jenkins
also wouldn't be. http://wiki.qt-project.org/Early_Warning_System
links to the EWS "sanity bot" script, Oswald could provide details on
how it is run.

> 
> My goal for this week is to at least have one build node connected to the
> system to build Qt, maybe track gerrit and to understand what the GAP between
> Pulse and Jenkins is. I am happy to give you admin privileges to the jenkins
> installation (you need to create the account first) and ssh to the jail that
> hosts jenkins.
> 

That could be helpful, if only because it seems I mightn't be able to see
the Jenkins config without these rights :)

> PS:
> 
> >> There is some documentation at 
> >> http://wiki.qt-project.org/index.php/Public_Autotest_Infrastructure
> >> which should be expanded.
> 
> this redirects to the mainpage

The wiki software seems to have been changed since I wrote the email.
http://wiki.qt-project.org/Public_Autotest_Infrastructure is now the
correct link.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New circular buffer container for Qt5

[Rohan McGovern]

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

Re: [Development] Keep dependent projects in mind when approving changes

[Rohan McGovern]

marius.storm-ol...@nokia.com said:
> Hi Maintainers and Approver,
> 
> Please keep in mind dependent modules when you approve and merge in
> changes which can lead to dependent projects failing. If you know that a
> commit has a risk of destabilizing other modules, please ensure that you
> are prepared to also do a fix in the dependent module, to help mitigate
> those libraries failing their CI runs.
> 
> I don't have the exact case handy right now, but have been told that
> recent commits in QtBase has made other modules fail their CI runs.
> 
> Given that non-Nokian personnel cannot yet see the CI results, please note
> that Nokian's need to help out a bit extra to flag the issues for others,
> until we have managed to put in place a system to expose the CI test
> results.
> 

Just to add a bit.  Although the CI results are not publicly available
in full, it is possible to be appraised of many source-incompatible
changes by keeping an eye on changes from Qt Submodule Update Bot (
http://codereview.qt-project.org/#dashboard,1000191 ).

That bot will twice daily attempt to update qt5.git with the tip of all
modules, so most significant source breaks ought to be detected within
12 hours of submission.

Here is an example of an update attempt which succeeded on the first
try: http://codereview.qt-project.org/6795

And an example of an update attempt which took several attempts as
various source-incompatible changes were handled:
http://codereview.qt-project.org/7109
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development