Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On quarta-feira, 24 de abril de 2013 10.24.18, Chris Adams wrote: Anyway, I agree with Lars: the QtQuick1 ones could be renamed. The ones declared in public headers cannot be simply removed. That would be source- and binary-incompatible. If we were to take that route, we should rename the ones in QtQml, so that QtQuick1 retains compatibility with Qt 4. No, we should just do what Olivier suggested. It solves the problem more neatly. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
Hi,
there has been quite many comments about why rebasing might be complicated for
some people, but so far I think the advantages for the WinRT branch has not
been highlighted. So let me try to summarize why the team thinks that it is
beneficial to do so:
a) We do lots of changes upstream and get them back into the WinRT branch very
quickly this way. Of course we could do that via other means, but
b) the team bases on dev and wants to ensure that integration back into dev
will be a simple step once the port is stable enough. Without any/much
rebasing/squashing/history-rewrite efforts when time has come. For both
previous ports (Android and iOS) there have been lots of discussions how to
get things back properly, where so far we failed to make everyone happy.
Taking a rebased branch seemed to be beneficial here.
I do agree to Kai that having some official guidelines will benefit future
ports as well, but I also fail to see why the WinRT branch now is so much of a
difference compared to other ones. Maybe we should move the discussion into a
generic one with WinRT being one example beside others instead of complaining
about WinRT, but getting to no conclusion after all.
BR,
Maurice
-Original Message-
From: development-bounces+maurice.kalinowski=digia@qt-project.org
[mailto:development-bounces+maurice.kalinowski=digia.com@qt-
project.org] On Behalf Of Oswald Buddenhagen
Sent: Tuesday, April 23, 2013 7:12 PM
To: development@qt-project.org
Subject: Re: [Development] Please warn of force pushes...
On Tue, Apr 23, 2013 at 09:46:03AM -0700, Thiago Macieira wrote:
On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote:
I, for one, will not touch any of the rebasing branches, not even to
test
them. It's too much work to rebase on top of a moving base.
i call that making a mountain out of a molehill.
$ git fetch
$ git rebase --onto @{u} HEAD~4
Would you call me experienced with Git?
Well, I have never successfully used git rebase --onto without reading the
man
page first and paying attention to the ASCII Art graphs.
that's unfortunate. :P
Besides, that's unwieldy. I don't carry a handful of commits in my branches.
I
carry somewhere from 60 to 120. So, no, moving target == off-limits for me.
this is an entirely constructed example. you are not going to have 100
changes on top of a wip branch which is too quickly moving to adhere to
the mainline submission policies.
and, ehm, you are the only person within qt-project who has 100 pending
changes in a single branch. seriously.
Especially if they're bypassing the CI, they could and should just use
a repository elsewhere. When the branch is ready, it will be submitted
as individual patches to be reviewed by the regular reviewers, maybe
starting the work branch.
it's unreasonable to ban everything that does not comply with the
standard workflow for mainline branches.
Yes, it is. Why do they need to use the mainline repositories if they are
not
going to adhere to the policies that are in place?
No, really, why do those branches need to be in the main repositories?
I'll give one answer, out of past discussion, and just to prove that yes I
am
trying to understand both sides:
it is nice to be there because other people sometimes see the commits
coming
in and will comment on them.
With that in mind, I change my proposal and I will say that rebasing
branches
are acceptable in the mainline repositories, provided they are clearly
marked.
It's minimal impact and it solves the problem of surprise by selecting the
people who may use that branch.
as far as i can see, the admin who created the winrt branch (not me)
failed to comply with the wip/ policy. i'm sure adding more naming
policies will improve that situation ... not.
and if you did, you'd need to ban playground repos as well (where
typically non-approvers can approve changes).
By definition, a playground repository is not a mainline repository.
but it lives on our gerrit, so it's official.
i don't see a difference between a non-mainline branch of an accepted
repository and the branches of a playground repository. there is no such
thing as a mainline _repository_ - on the server, we don't clone: we
branch.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On Tue, Apr 23, 2013 at 11:22 PM, Thiago Macieira thiago.macie...@intel.com wrote: On quarta-feira, 24 de abril de 2013 10.24.18, Chris Adams wrote: Anyway, I agree with Lars: the QtQuick1 ones could be renamed. The ones declared in public headers cannot be simply removed. That would be source- and binary-incompatible. If we were to take that route, we should rename the ones in QtQml, so that QtQuick1 retains compatibility with Qt 4. Qt 5.0 has been released and also needs compatibility. So it's just as valid to rename the ones in QtQuick1 so that QtQml retains compatibility with Qt 5. No, we should just do what Olivier suggested. It solves the problem more neatly. I agree. I'm just waiting for someone to push the patch to codereview. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Wednesday 24 April 2013 06:28:43 Kalinowski Maurice wrote: Hi, there has been quite many comments about why rebasing might be complicated for some people, but so far I think the advantages for the WinRT branch has not been highlighted. So let me try to summarize why the team thinks that it is beneficial to do so: a) We do lots of changes upstream and get them back into the WinRT branch very quickly this way. Of course we could do that via other means, but Normaly, the way git was designed, is to use merges for this workflow. In principle, rebasing should only be used for private branches. And the winrt is not private. Not only it is public, but it is even part of the main repsitory. You should only merge with dev when you really need a change from dev. You may also cherry pick, if you only want a single change. Rebasing is harmfull if anyone else if following this branch. So I would recommand doing merges instead of rebasing. b) the team bases on dev and wants to ensure that integration back into dev will be a simple step once the port is stable enough. Without any/much rebasing/squashing/history-rewrite efforts when time has come. Merging should be even easize than rebasing. For both previous ports (Android and iOS) there have been lots of discussions how to get things back properly, where so far we failed to make everyone happy. Taking a rebased branch seemed to be beneficial here. I think the proper way to do it is to have the relevant maintainers of the code look at the non-trivial patches already now. I beleive it was one of the problem with the android port, that it is a bit like a code drop when reviewing was too late. I do agree to Kai that having some official guidelines will benefit future ports as well, but I also fail to see why the WinRT branch now is so much of a difference compared to other ones. Maybe we should move the discussion into a generic one with WinRT being one example beside others instead of complaining about WinRT, but getting to no conclusion after all. I encourage to use merges instead of rebasing. That say, git has many possible workflows, and if rebasing is really better for the people working on winrt, then let it be. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Git mirror in github?
Hi, all, Before Open Governance, we have the public git repo on gitorious. But now codereview(gerrit) is the main repo, and gitorious one is only mirror of it. GitHub is much more popular and stable than gitorious, could we have a git mirror there? Thanks. Regards, Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Making WEC7 builds blocking on CI
Hi, As you probably have noted, Qt-Project CI have had WEC7 ARM build jobs running in a non-blocking mode for a while. The jobs are build only, and don't execute any autotests. Now that Björn Breitmeyer has been proposed as a maintainer for Windows Embedded, and there have not been any objections so far, I would like to start making WEC7 builds blocking for those modules where build passes. Having builds blocking would make it much easier to keep WEC7 in good shape. I'm sure Björn and other WEC7 contributors (including at least myself and Andreas Holzammer from KDAB), are happy to help you if you face any build problems due to blocking WEC7 build. Any objections? Br, -- Janne Anttila Senior Architect - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtNetwork performance improvements
Hello, for reference: I have just created a Wiki page about QtNetwork performance improvements at http://qt-project.org/wiki/QtNetwork_performance One interesting quote: In the particular case of code issuing a network request, the time spent in parsing the HTTP replies, computing SSL keys etc. takes less than 5% of the overall time, i.e. 95% of the time below is spent in waiting for network I/O. In other words: When trying to improve QtNetwork performance, try to shave off network roundtrips and reduce latency rather than trying to improve parsing of HTTP replies / avoiding memcpy etc. Feel free to comment / ask / suggest etc. Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Git mirror in github?
On Wednesday 24 April 2013 09:32:55 Qi Liang wrote: Hi, all, Before Open Governance, we have the public git repo on gitorious. But now codereview(gerrit) is the main repo, and gitorious one is only mirror of it. GitHub is much more popular and stable than gitorious, could we have a git mirror there? Thanks. If what you like is a nice web interface to browse Qt code, I am maintaining browsable version of the Qt dev branch in http://code.woboq.org/qt5/ And (also qt4 in http://code.woboq.org/kde/qt4/ ) (I update about once a month) Example: http://code.woboq.org/qt5/qt-creator/src/app/main.cpp.html?style=qtcreator#main -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Wed, Apr 24, 2013 at 09:23:54AM +0200, Olivier Goffart wrote: Normaly, the way git was designed, is to use merges for this workflow. In principle, rebasing should only be used for private branches. And the winrt is not private. Not only it is public, but it is even part of the main repsitory. You should only merge with dev when you really need a change from dev. You may also cherry pick, if you only want a single change. Rebasing is harmfull if anyone else if following this branch. So I would recommand doing merges instead of rebasing. the thing is, if you want to merge to a mainline, each of your commits needs to comply with all of a mainline's policies, because your commits will become part of the mainline. this is not the case with winrt (and previous ports). therefore, the discussion is already over at this point. but rebasing has other advantages, too. one is that conflicted merges are inherently evil. therefore, the fewer merges, the better. the second is that a clean workflow (discussion with concerned maintainers, submission for the right branch, integration, forward-merging) has a way too high latency. consequently, the teams take many shortcuts, which violates pretty much every aspect of the commit policy and produces a terrible history. rebasing is the only way to get that straightened out without holding up the ad-hoc development. the last (and imo deciding) point is: if the concerned team likes this workflow, it is good. it's ridiculous to make concessions for hypothetical drive-by contributors. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making WEC7 builds blocking on CI
Hey, I fully agree with Janne here, as normally its not so hard to fix Windows Embedded Compact issue, but if we let it run and try to fix it after a month or so, its very hard and takes time, as one need to understand the code and maybe even needs talking to the author of the patch. So I would really love to see the WEC7 CI enforcing. Thank you Janne for all the patches and all the efforts Andy Am 24.04.2013 11:40, schrieb Anttila Janne: Hi, As you probably have noted, Qt-Project CI have had WEC7 ARM build jobs running in a non-blocking mode for a while. The jobs are build only, and don't execute any autotests. Now that Björn Breitmeyer has been proposed as a maintainer for Windows Embedded, and there have not been any objections so far, I would like to start making WEC7 builds blocking for those modules where build passes. Having builds blocking would make it much easier to keep WEC7 in good shape. I'm sure Björn and other WEC7 contributors (including at least myself and Andreas Holzammer from KDAB), are happy to help you if you face any build problems due to blocking WEC7 build. Any objections? Br, -- Janne Anttila Senior Architect - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Andreas Holzammer | andreas.holzam...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME Kryptografische Unterschrift ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Network test server for Ubuntu 12.04 x64 available for Puppet - test version
Hi For all you who have tried to install a network test server: a Puppet configuration for Ubuntu 12.04 x64 is now available. It's still in my personal Gitorious branch, as it still needs testing before pushed through to production. Also I will flag these 12.04 changes so that we still have the 10.04 configuration left there. All qtbase networkselftests passed with this, but there might still be something I missed in the configuration. Tomorrow I'll reinstall a server from scratch using this myself to see what I might have missed. https://qt.gitorious.org/~tosaraja/qtqa/tosarajas-sysadmin-nts Send any feedback straight to me :) Good luck! -Tony Tony Sarajärvi Senior Software Designer Digia, Qt Digia Plc Elektroniikkatie 10 FI-90590 Oulu Email: tony.saraja...@digia.commailto:tony.saraja...@digia.com IRC: freenode - #qt-qa Mobile: +358 050 482 1416 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qtcommercialhttp://www.facebook.com/qtcommercial Qt Twitter: www.twitter.com/qtcommercialhttp://www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. -- ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about the missing projects in qt-solutions
I know the background for this pretty well since I was involved with the original transfer of the solution code from TT to Nokia. Basically the code was not transferred to Digia at all and it was not initially made publically available either when the code was released under the BSD license when Nokia had control of it. So the code itself isn't available anymore to put into gitorious unfortunately. There is nothing that can be done about this anymore I am afraid unless Nokia still has a copy somewhere and chooses to make it available then nothing can be done. Andy From: development-bounces+andy.shaw=digia@qt-project.org [mailto:development-bounces+andy.shaw=digia@qt-project.org] On Behalf Of Qi Liang Sent: 24. april 2013 12:05 To: development@qt-project.org; Knoll Lars Subject: [Development] Question about the missing projects in qt-solutions Hi, all, Some friends in Chinese local qt forum started to talk about this issue. Current qt-solutions repo: https://codereview.qt-project.org/#admin,project,qt-solutions/qt-solutions,info http://qt.gitorious.org/qt-solutions/qt-solutions/ But there are only 9 in total. Based on the documentation, (someone mirrored the qt solutions for qt 4), it should be about 38. http://docs.huihoo.com/qt/solutions/4/ And digia still has the docs, but missing the main page for the directory, like http://doc.qt.digia.com/solutions/4/qtmmlwidget/index.html I guess nokia transfered all qt solutions to digia. Lars, could you confirm that? If so, could we put them back to qt-solutions repo? Regards, Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Tue, Apr 23, 2013 at 08:02:23PM +0200, Koehne Kai wrote:
Hi guys,
don't want to stop your discussion, but personally I see that mainly as a
documentation issue. Surely having some convention about branch names (and
sticking to it) would help, but even better would be to put the details about
the branches on something that shows up very high in google qt git branches
:) Right now there's
http://qt-project.org/wiki/Branches
which is qt creator only. We should have the same for qt.git, or list both on
the page.
this is a very good point.
in fact, there were/are several branches in qtbase where i simply don't
know what they are for (which is kinda suboptimal, given that i'm
supposed to be one of the admins). i have repeatedly been chasing behind
people to find out who is responsible and whether a branch is still
relevant.
i made some additions to the existing page. i expect the branch owners
to fill the sections with meat and add any missing branches (from other
repos than qtbase).
also, somebody with a better overview of the wiki structure should
add/replace the category tags to mark the page as relevant also for qt,
and link the page appropriately.
Regards
Kai
PS: Yet another example: http://gcc.gnu.org/svn.html, where all the gcc
branches are described.
From: development-bounces+kai.koehne=digia@qt-project.org
[development-bounces+kai.koehne=digia@qt-project.org] on behalf of Oswald
Buddenhagen [oswald.buddenha...@digia.com]
Sent: 23 April 2013 19:11
To: development@qt-project.org
Subject: Re: [Development] Please warn of force pushes...
On Tue, Apr 23, 2013 at 09:46:03AM -0700, Thiago Macieira wrote:
On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote:
I, for one, will not touch any of the rebasing branches, not even to
test
them. It's too much work to rebase on top of a moving base.
i call that making a mountain out of a molehill.
$ git fetch
$ git rebase --onto @{u} HEAD~4
Would you call me experienced with Git?
Well, I have never successfully used git rebase --onto without reading the
man
page first and paying attention to the ASCII Art graphs.
that's unfortunate. :P
Besides, that's unwieldy. I don't carry a handful of commits in my
branches. I
carry somewhere from 60 to 120. So, no, moving target == off-limits for me.
this is an entirely constructed example. you are not going to have 100
changes on top of a wip branch which is too quickly moving to adhere to
the mainline submission policies.
and, ehm, you are the only person within qt-project who has 100 pending
changes in a single branch. seriously.
Especially if they're bypassing the CI, they could and should just use
a repository elsewhere. When the branch is ready, it will be submitted
as individual patches to be reviewed by the regular reviewers, maybe
starting the work branch.
it's unreasonable to ban everything that does not comply with the
standard workflow for mainline branches.
Yes, it is. Why do they need to use the mainline repositories if they are
not
going to adhere to the policies that are in place?
No, really, why do those branches need to be in the main repositories?
I'll give one answer, out of past discussion, and just to prove that yes I
am
trying to understand both sides:
it is nice to be there because other people sometimes see the commits coming
in and will comment on them.
With that in mind, I change my proposal and I will say that rebasing
branches
are acceptable in the mainline repositories, provided they are clearly
marked.
It's minimal impact and it solves the problem of surprise by selecting the
people who may use that branch.
as far as i can see, the admin who created the winrt branch (not me)
failed to comply with the wip/ policy. i'm sure adding more naming
policies will improve that situation ... not.
and if you did, you'd need to ban playground repos as well (where
typically non-approvers can approve changes).
By definition, a playground repository is not a mainline repository.
but it lives on our gerrit, so it's official.
i don't see a difference between a non-mainline branch of an accepted
repository and the branches of a playground repository. there is no such
thing as a mainline _repository_ - on the server, we don't clone: we
branch.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making WEC7 builds blocking on CI
On quarta-feira, 24 de abril de 2013 12.41.15, Andreas Holzammer wrote: Hey, I fully agree with Janne here, as normally its not so hard to fix Windows Embedded Compact issue, but if we let it run and try to fix it after a month or so, its very hard and takes time, as one need to understand the code and maybe even needs talking to the author of the patch. So I would really love to see the WEC7 CI enforcing. Thank you Janne for all the patches and all the efforts What's the track record for that build? Can you guys share what the most common failures have been in the past? What are the things people should be aware of? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Network test server for Ubuntu 12.04 x64 available for Puppet - test version
Hi Tony, Thanks for working on this. I found some issues so far: You didn't add a bootstrap script for ubuntu 12.04 When using the 10.04 script, the file /etc/apt/sources.list.d/bootstrap-puppet.list is invalid, causing the script to abort. When using the 11.10 script, it fills the log with Skipping because of failed dependencies, and Could not evaluate: Could not retrieve information from environment production source(s) README.network_test_server.txt needs to be updated too. The existing scripts have not worked for setting up network test server since the move from Nokia to Digia, so some of the failures may be due to this pre-existing problem. -- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Sarajärvi Tony Sent: 24 April 2013 13:33 To: development@qt-project.org Subject: [Development] Network test server for Ubuntu 12.04 x64 available for Puppet - test version Hi For all you who have tried to install a network test server: a Puppet configuration for Ubuntu 12.04 x64 is now available. It's still in my personal Gitorious branch, as it still needs testing before pushed through to production. Also I will flag these 12.04 changes so that we still have the 10.04 configuration left there. All qtbase networkselftests passed with this, but there might still be something I missed in the configuration. Tomorrow I'll reinstall a server from scratch using this myself to see what I might have missed. https://qt.gitorious.org/~tosaraja/qtqa/tosarajas-sysadmin-nts Send any feedback straight to me :) Good luck! -Tony Tony Sarajärvi Senior Software Designer Digia, Qt Digia Plc Elektroniikkatie 10 FI-90590 Oulu Email: tony.saraja...@digia.commailto:tony.saraja...@digia.com IRC: freenode - #qt-qa Mobile: +358 050 482 1416 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qtcommercialhttp://www.facebook.com/qtcommercial Qt Twitter: www.twitter.com/qtcommercialhttp://www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. -- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making WEC7 builds blocking on CI
Hey, thanks for you effort. The enforcing build would be very helpful. The most important issues we had during the last few month were changes in qmake, arch detection :) and some additions to the windows plugin. Besides changes to the windows platform plugin most changes were not really troubling, its usually about platform plugin features that are not available on windows ce. What more people should actually care about and which is not tested by the ci yet is that we had real issues with people break QT_NO_... there are some hard things we just don't have on windows ce and we run into those quite often. So if you add new patches it would be great to look out of for QT_NO_CURSOR QT_NO_ACCESSIBILITY QT_NO_PRINTER an more stuff like that. If you happen to work on the windows platform plugin, here are some recommendations. If you have functions taking strings that come in an A and W version( ansi and widestring(utf16) ) use the W version as that is usually available on ce too. And if you are unsure if the winapi function you used is available on ce too, just google function name msdn wince and you will usually get your answer in matter of a seconds. Besides that we of course had our low level arm fun, but thats mostly sorted out until there is a new javascriptengine. Best regards Björn Breitmeyer Am Mittwoch, 24. April 2013, 08:25:06 schrieb Thiago Macieira: On quarta-feira, 24 de abril de 2013 12.41.15, Andreas Holzammer wrote: Hey, I fully agree with Janne here, as normally its not so hard to fix Windows Embedded Compact issue, but if we let it run and try to fix it after a month or so, its very hard and takes time, as one need to understand the code and maybe even needs talking to the author of the patch. So I would really love to see the WEC7 CI enforcing. Thank you Janne for all the patches and all the efforts What's the track record for that build? Can you guys share what the most common failures have been in the past? What are the things people should be aware of? -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] PSA: Qt Project IRC logs statistics
Hi, In addition to hosting qt_gerrit, I have for a very long time generated IRC statistics for #qt and #qt-labs. These were perhaps not all that well publicized, but they did exist. After my recent server outage, obviously, this all got lost. I got around to restoring it this evening (see http://qt.viroteck.net/irc/), and I've also published logs for #qt and #qt-labs which I did not do previously due to laziness. I can do other channels on request (as usual). There isn't much there yet, but the statistics are set to auto-generate at the server's idea of midnight, so checking back in a few days should give more interesting results, provided I've remembered how to use crontab correctly. I've documented both this (and qt_gerrit) at https://qt-project.org/wiki/IRC Thanks, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] EGL is somehow showing up in Qt5GuiConfigExtras.cmake on desktop Linux
I just updated to latest stable, and somehow: _qt5gui_find_extra_libs(EGL EGL ) _qt5gui_find_extra_libs(OPENGL GL ) are both ending up in Qt5GuiConfigExtras.cmake, even though I've configured for desktop OpenGL. This causes my cmake-based project to fatal error because it can't find EGL: Failed to find EGL in , using the CMAKE_FIND_ROOT_PATH . The problem is not in the 5.1 alpha, and looks like it got introduced by http://qt.gitorious.org/qt/qtbase/commit/a680fe609f9b8cbccee1acd7391a725cf4b7b523 OSX and Windows-ANGLE work fine. Is anyone else seeing this? The configure output: *[23:11:51]**Build type: linux-g++-64 (x86_64, CPU features: mmx sse sse2)* *[23:11:51]*** *[23:11:51]**Build options:* *[23:11:51]** Configuration .. accessibility accessibility-atspi-bridge alsa audio-backend avx c++11 clock-gettime clock-monotonic concurrent dbus evdev eventfd fontconfig full-config getaddrinfo getifaddrs glib gtk2 gtkstyle iconv icu inotify ipv6ifname large-config largefile libudev linuxfb medium-config minimal-config mremap nis opengl openssl pcre png precompile_header pulseaudio qpa qpa reduce_exports reduce_relocations release rpath shared small-config sse2 sse3 sse4_1 sse4_2 ssse3 system-freetype system-png system-zlib v8 v8snapshot xcb xcb-qt xcb-xlib xinput2 xlib xrender * *[23:11:51]** Build parts libs tools* *[23:11:51]** Mode ... release* *[23:11:51]** Using C++11 yes* *[23:11:51]** Using PCH .. yes* *[23:11:51]** Target compiler supports:* *[23:11:51]** SSE2/SSE3/SSSE3 .. yes/yes/yes* *[23:11:51]** SSE4.1/SSE4.2 yes/yes* *[23:11:51]** AVX/AVX2 . yes/no* *[23:11:51]*** *[23:11:51]**Qt modules and options:* *[23:11:51]** Qt D-Bus ... yes (loading dbus-1 at runtime)* *[23:11:51]** Qt Concurrent .. yes* *[23:11:51]** Qt GUI . yes* *[23:11:51]** Qt Widgets . yes* *[23:11:51]** JavaScriptCore JIT . To be decided by JavaScriptCore* *[23:11:51]** QML debugging .. yes* *[23:11:51]** Use system proxies . no* *[23:11:51]*** *[23:11:51]**Support enabled for:* *[23:11:51]** Accessibility .. yes* *[23:11:51]** ALSA ... yes* *[23:11:51]** CUPS ... no* *[23:11:51]** FontConfig . yes* *[23:11:51]** Iconv .. yes* *[23:11:51]** ICU yes* *[23:11:51]** Image formats:* *[23:11:51]** GIF .. plugin* *[23:11:51]** JPEG . plugin (qt)* *[23:11:51]** PNG .. yes (system)* *[23:11:51]** Glib ... yes* *[23:11:51]** GStreamer .. no* *[23:11:51]** GTK theme .. yes* *[23:11:51]** Large Files yes* *[23:11:51]** Networking:* *[23:11:51]** getaddrinfo .. yes* *[23:11:51]** getifaddrs ... yes* *[23:11:51]** IPv6 ifname .. yes* *[23:11:51]** OpenSSL .. yes (loading libraries at run-time)* *[23:11:51]** NIS yes* *[23:11:51]** OpenGL . yes (Desktop OpenGL)* *[23:11:51]** OpenVG . no* *[23:11:51]** PCRE ... yes (qt)* *[23:11:51]** pkg-config . yes* *[23:11:51]** PulseAudio . yes* *[23:11:51]** QPA backends:* *[23:11:51]** DirectFB . no* *[23:11:51]** EGLFS no* *[23:11:51]** KMS .. no* *[23:11:51]** LinuxFB .. yes* *[23:11:51]** XCB .. qt* *[23:11:51]** MIT-SHM auto* *[23:11:51]** Xcursor yes* *[23:11:51]** Xfixes . yes* *[23:11:51]** Xi . no* *[23:11:51]** Xi2 yes* *[23:11:51]** Xinerama ... yes* *[23:11:51]** Xrandr . yes* *[23:11:51]** Xrender yes* *[23:11:51]** XKB yes* *[23:11:51]** XShape . yes* *[23:11:51]** XSync .. auto* *[23:11:51]** XVideo . auto* *[23:11:51]** Session management . auto* *[23:11:51]** SQL drivers:* *[23:11:51]** DB2 .. no* *[23:11:51]** InterBase no* *[23:11:51]** MySQL plugin* *[23:11:51]** OCI .. no* *[23:11:51]** ODBC . no* *[23:11:51]** PostgreSQL ... no* *[23:11:51]** SQLite 2 . no* *[23:11:51]** SQLite ... plugin (qt)* *[23:11:51]** TDS .. no* *[23:11:51]** udev ... yes* *[23:11:51]** xkbcommon .. no* *[23:11:51]** zlib ... yes (system* ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Network test server for Ubuntu 12.04 x64 available for Puppet - test version
Hi Ah yes, I could have added the bootstrap, although it would just have been a copy of 11.10. I'm wondering why it didn't work for you. Is the log you refer to Puppet's log? Can you send it to me, and I'll have a look at it? And yes, lots of documentation still need working on. I just bundled up all my changes I had done so far and gave it to you as soon as I got all needed services up and running. Of the pre-existing problems, I also worked on cleaning up the puppet log, so that it doesn't try to start the services on each puppet run. Regards, -Tony From: shane.kea...@accenture.com [mailto:shane.kea...@accenture.com] Sent: 24. huhtikuuta 2013 18:26 To: Sarajärvi Tony; development@qt-project.org Subject: RE: [Development] Network test server for Ubuntu 12.04 x64 available for Puppet - test version Hi Tony, Thanks for working on this. I found some issues so far: You didn't add a bootstrap script for ubuntu 12.04 When using the 10.04 script, the file /etc/apt/sources.list.d/bootstrap-puppet.list is invalid, causing the script to abort. When using the 11.10 script, it fills the log with Skipping because of failed dependencies, and Could not evaluate: Could not retrieve information from environment production source(s) README.network_test_server.txt needs to be updated too. The existing scripts have not worked for setting up network test server since the move from Nokia to Digia, so some of the failures may be due to this pre-existing problem. -- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Sarajärvi Tony Sent: 24 April 2013 13:33 To: development@qt-project.org Subject: [Development] Network test server for Ubuntu 12.04 x64 available for Puppet - test version Hi For all you who have tried to install a network test server: a Puppet configuration for Ubuntu 12.04 x64 is now available. It's still in my personal Gitorious branch, as it still needs testing before pushed through to production. Also I will flag these 12.04 changes so that we still have the 10.04 configuration left there. All qtbase networkselftests passed with this, but there might still be something I missed in the configuration. Tomorrow I'll reinstall a server from scratch using this myself to see what I might have missed. https://qt.gitorious.org/~tosaraja/qtqa/tosarajas-sysadmin-nts Send any feedback straight to me :) Good luck! -Tony Tony Sarajärvi Senior Software Designer Digia, Qt Digia Plc Elektroniikkatie 10 FI-90590 Oulu Email: tony.saraja...@digia.commailto:tony.saraja...@digia.com IRC: freenode - #qt-qa Mobile: +358 050 482 1416 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qtcommercialhttp://www.facebook.com/qtcommercial Qt Twitter: www.twitter.com/qtcommercialhttp://www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. -- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.comhttp://www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
