Re: [Development] New proposal for the tool naming
Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build You definitely don't want support multiarch configurations out-of-the-box :) Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5 /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86` (or even with `qmake -set-qt 5x86` if you created a symlink to the 5.0-x86's config file). And yeah, switching the system-default Qt for all users just to build some crappyhelloworldexample .pro is a shiny new great idea :) Konstantin 2012/10/24 Lincoln Ramsay a1291...@gmail.com: On 24/10/12 04:33, Thiago Macieira wrote: I think we are keeping it simple. The current proposal is the simplest that still works. If you can come up with something even simpler, I'll gladly accept it. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? Drop it. I know I complained about renaming qmake but... it would be simpler to rename qmake to qmake5 than to have a 'special' qmake that may or may not be the qmake that's first in your PATH and that may or may not do something with a -qtx switch. So I'm going to remove my +1 for the 'special' qmake and instead suggest a much simpler solution. This is just for 'qmake' though, everything else... same as it was before. Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build Optional: Create libexec/bin/qmake as a symlink to qmake5 (for Windows... a .bat or .cmd may work, else a copy). The officially supported way to build thus becomes qmake5 and it is guaranteed to work no matter what platform you're on or how you've set your PATH. Yes, we have to update all the documentation. The optional symlink is for complainers like me, so we can continue to run qmake - but only if we set PATH correctly first. It'll also help with old instructions, scripts, etc. that would break if we just renamed qmake ;) -- Link ___ 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] Proposal: Change Qt's Security Policy to Full Disclosure
On 10/24/2012 01:12 AM, d3fault wrote: On 10/23/12, Lincoln Ramsay a1291...@gmail.com wrote: We're not renaming things or creating new lists just to match the names you think we should have. *sigh*, I had a feeling someone would say something like that. The changes are trivial at a glance, yes ...but what the Qt Project officially endorses/recommends is the real change here. Right now, the Qt Project instructs analysts use security-through-obscurity when reporting vulnerabilities. Lars and Charles both provided good lists of reasons in another part of this thread for going with the policy of Responsible Disclosure. Clearly you disagree on the weighting of the pros and cons, but it doesn't seem like you're able to convince anyone else about the superiority of your position. At what point will you accept that? -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QmlImportPath
Hi everybody, we are still having problems with the QmlImportPath. There is also already a bug reported: https://bugreports.qt-project.org/browse/QTBUG-20539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel Reminder: The problem looks like this. We have a custom plugin which is installed in the default import directory in the Qt path. Here it works fine with any Qml files. The problem occurs if we want to change the location of the plugin. For example we moved it to the directory of the executable. It is recognized, that there is a plugin there. Anyway we just get a white screen and the following error message: File name case mismatch for CORRECT_PATH_TO_PLUGIN I've also found this: http://doc.qt.digia.com/qt-quick3d-snapshot/qt3d-troubleshooting.html#problem-7-case-mis-match-on-loading-qml-plugins (Problem 7). Probably they are connected. Does anyone know, if this is gonna be solved in the Qt 5 RC1? In my opinion this is a really bothering issue that should be resolved quickly as it is a potential cause of many errors, that are hard to detect. Maybe you have more information on this topic or now another solution then just reinstallaing everything without any Capital letters in the paths. :) Greetings Matthias --- This communication contains confidential information. If you are not the intended recipient please return this email to the sender and delete it from your records. Diese Nachricht enthaelt vertrauliche Informationen. Sollten Sie nicht der beabsichtigte Empfaenger dieser E-mail sein, senden Sie bitte diese an den Absender zurueck und loeschen Sie die E-mail aus Ihrem System. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On 23 Oct 2012, at 19:03, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote: So that if you happen to have a real qmake instead of the wrapper in the PATH on linux, you don't realize that when you are doing qmake -qt5 to force most current qt5 version (or whatever the semantics would be), you actually execute a completely different qmake? I don't think that would be a good idea. It will do that too if it's in a separate build looking at a non-standard configuration path. I don't get what you mean with that. Er... convoluted way of saying that if you only have one Qt build visible from the wrapper, qmake -qt5 can mean exactly one Qt build. Therefore, by exclusion of any other alternatives, it's the most recent build available :-) In any case, -qt5 may not mean latest, but simply default 5.x version. The implementation will decide what that means. qmake -qt5 would *not* mean default or latest (whatever the implementation will decide), if there is a specific version of qmake in the PATH, instead of the wrapper. From a usability standpoint it would be much safer to bail out with an error if you use qmake -qtXYZ on a specific version of qmake instead of the wrapper, because it wouldn't do what you'd expect it to do. That's mostly what's going to happen on Windows anyway, isn't it? My concerns are about having -qt5 ignored for the real qmake on linux. On Windows and Mac the -qt option is useless anyhow (which makes it questionable to use it there IMO, so it makes it questionable to use it in the documentation that way too IMO) I think all this becomes much too confusing. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? Because you wouldn't be able to use -qt4 or -qt=5.0.1. You don't want to just document it (as in qmake (the wrapper on Linux) also takes the -qt[=version] option), but want to use it everywhere in the documentation where qmake is called. That creates expectations about how qmake works, though it is just referring to how the qmake wrapper on Linux works. -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On 24 Oct 2012, at 08:04, Konstantin Ritt ritt...@gmail.com wrote: Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build You definitely don't want support multiarch configurations out-of-the-box :) Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5 /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86` (or even with `qmake -set-qt 5x86` if you created a symlink to the 5.0-x86's config file). And yeah, switching the system-default Qt for all users just to build some crappyhelloworldexample .pro is a shiny new great idea :) qmake -set… would/should/must certainly set a *user* specific default. (There'd need to be other mechanisms for distributors and admins to set the system wide default.) Konstantin 2012/10/24 Lincoln Ramsay a1291...@gmail.com: On 24/10/12 04:33, Thiago Macieira wrote: I think we are keeping it simple. The current proposal is the simplest that still works. If you can come up with something even simpler, I'll gladly accept it. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? Drop it. I know I complained about renaming qmake but... it would be simpler to rename qmake to qmake5 than to have a 'special' qmake that may or may not be the qmake that's first in your PATH and that may or may not do something with a -qtx switch. So I'm going to remove my +1 for the 'special' qmake and instead suggest a much simpler solution. This is just for 'qmake' though, everything else... same as it was before. Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build Optional: Create libexec/bin/qmake as a symlink to qmake5 (for Windows... a .bat or .cmd may work, else a copy). The officially supported way to build thus becomes qmake5 and it is guaranteed to work no matter what platform you're on or how you've set your PATH. Yes, we have to update all the documentation. The optional symlink is for complainers like me, so we can continue to run qmake - but only if we set PATH correctly first. It'll also help with old instructions, scripts, etc. that would break if we just renamed qmake ;) -- Link ___ 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 -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QmlImportPath
-Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [mailto:development-bounces+kai.koehne=digia@qt-project.org] On Behalf Of Wehmer, Matthias Sent: Wednesday, October 24, 2012 9:56 AM To: development@qt-project.org Subject: [Development] QmlImportPath Hi everybody, we are still having problems with the QmlImportPath. There is also already a bug reported: https://bugreports.qt-project.org/browse/QTBUG- 20539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel https://bugreports.qt-project.org/browse/QTBUG- 20539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel Sounds pretty much like https://bugreports.qt-project.org/browse/QTBUG-17529 , or a variant of it. I don't know whether the patch I've proposed at https://codereview.qt-project.org/#change,33415 would help you though, since it fixes the problem only for absolute paths set to QtQUickView::setSource and QQmLEngine::setBaseUrl ... Actually I'm more than ever convinced that QML shouldn't check for file case sensitivity at all (on case insensitive file systems), or at least not in folder names. Feel free to vote. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating Serializing Qt Data Types documentation
On Tuesday 23. October 2012 19.34.46 Harri Porten wrote: On Tue, 23 Oct 2012, Mitch Curtis wrote: After https://codereview.qt-project.org/#change,37988, the Serializing Qt Data Types page lists the QDataStream version as 13. I thought it'd be a good idea to ask everyone who is interested to take a look and see if the descriptions of the data types serialised are still accurate. If they're not, please update the page (the path to which can be found in the aforementioned patch). Coincidentally we noticed a over-the-wire serialization problem today. With QVariant. But it's likely not an issue with above mentioned format version 13. Rather with a backward compat mode. Do I see it correctly that tests/ only cover 4.9 and 5.0 versions? Hmmm. I now realize that I can answer this question myself given that the coverage results we just posted... http://download.froglogic.com/public/qt5-squishcoco-report/QtBase/source_1 43.html (see QVariant::load() and save()) We'll investigate what's going on and submit a patch if it's a problem in QVariant or QDataStream. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Hi, I added that tests durring Qt5 development, sadly streaming was never tested with older versions. What is the bug, can I help somehow? Is it only Qt5 or Qt4 too? Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
On 10/24/12, Samuel Rødal samuel.ro...@digia.com wrote: Lars and Charles both provided good lists of reasons in another part of this thread for going with the policy of Responsible Disclosure. Clearly you disagree on the weighting of the pros and cons, but it doesn't seem like you're able to convince anyone else about the superiority of your position. At what point will you accept that? dubtef' you're right, I completely missed Lars' response somehow :-/. I think I've logically proven a vulnerability exists within the Qt Security Policy. I think what I'm proposing is reasonable. It accommodates both responsible and full disclosure. Yes I can be an arsehole at times (triggered especially when I'm talked down to: let us make important decisions for you ... and basically this whole you have to trust us with your security mentality), but skipping over the argument completely and focusing only on my bad behavior is even worse than the bad behavior itself. I should have pseudonym + nice'd this argument, probably would have it by now. Now we're at the point where those in charge don't want to give a whiny child his way. Remember, even a broken clock is right twice a day ;-). At what point will you accept that? You're asking me at what point I'll stop caring about security... ...uhmmm When will you stop locking your doors at night? When will you stop scanning binaries for virus' (lol as if that does anything :-P)? etc etc So I'm late with this, here's my Charley/Lars rebuttal: On 10/20/12, Knoll Lars lars.kn...@digia.com wrote: In many cases it's unreasonable to ask people to shut down the services because it's simply too expensive. Think about a mobile phone like the N9. Do you really expect people to turn their phone off for an unknown amount of time because there's an exploit? If they value and practice security, ABSOLUTELY. Most end-users do neither. Why should I (we) suffer for that? Do you think end users can even judge the criticality of the exploit and what kind of measures they could take to avoid it? They can't. Often even we, the main developers behind Qt, can't know what kind of measures and end user needs to use to protect himself, because we don't know how exactly Qt is being used in the product. Precisely why you should allow the _user_ to decide for himself. Of course one needs to publish fixes for security issues and do updates and disclose the problem. But if the issue is not widely known already, we have a chance to already provide a fix when we disclose it. The best way I can see is to keep these private (for a limited period of time) and work with the experts in the area where the issue is to get it fixed as fast as possible. See: http://lists.qt-project.org/pipermail/development/2012-October/007381.html (Scenario:) and http://lists.qt-project.org/pipermail/development/2012-October/007384.html Most open source projects use a closed security list for exactly the reasons above. Even Debian who you cite as a reference has it, and they are coordinating disclosure dates with other vendors. Read http://www.debian.org/security/ once again, and don't only cite one sentence in there out of context. So we will be in good company here, following a process very similar to most other OSS projects, including most Linux distributions, WebKit, Apache and many others. I shouldn't have referred to Debian, I see that now. OpenBSD is still a shining example of a secure* product that uses full disclosure. Referring to other insecure products is irrelevant. Note: a piece of software is insecure by default unless measures are taken to make it secure. Even then, it's something you strive for knowing you cannot attain it. Like perfection. It's still very much worth striving for, however. * = security is a state, security policies are a process. Processes can be improved. And to make it clear: The Qt project will do full disclosure of the issues. The variant we'll be using is in wikipedia called 'Responsible Disclosure'. No, it's not a variant. They are the two competing public disclosure models. Full = disclosure at discovery Responsible = disclosure after fix On 10/20/12, Charley Bay charleyb...@gmail.com wrote: Your concession is interesting: His proposal is alright, with the exception of handling incoming vulnerabilities. That was not previously clear to me in the discussion You, like most, didn't read the thread (incl. links) in its entirety before responding. That's part of the problem too: debating random people that just respond out of the blue I THINK RESPONSIBLE DISCLOSURE IS BETTER AND SO DO MOST PROJECTS (See: http://lists.qt-project.org/pipermail/development/2012-October/007367.html ). No reason provided, just a random opinion repeated time and time again, which unfortunately still sways consensus :(. I count at least 4 that made that very argument (if you even want to call it that). Lars Knoll included. (a1)
Re: [Development] Updating Serializing Qt Data Types documentation
On Wed, 24 Oct 2012, Jedrzej Nowacki wrote: I added that tests durring Qt5 development, sadly streaming was never tested with older versions. What is the bug, can I help somehow? Is it only Qt5 or Qt4 too? We found the reason now: https://bugreports.qt-project.org/browse/QTBUG-27700 Streaming of invalid QVariants with Qt 5 for older versions does not work anymore. The test attached to above report isn't really elegant, yet. We'll improve upon that and try to submit a patch. Stay tuned. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Contributors Day 2012 Berlin
Hi everybody! As you may remember from last year, the Qt Developer Days in both Munich and San Francisco, on the first day of the conference there were two options: Training and the Qt Contributors Day. This year will be no different, and so, i am very happy to announce the immediate opening of registration for the Qt Contributors Day! Todo list: 1. Register 2. Figure out some good topics for discussions 3. Join us on the day http://qt-project.org/wiki/Qt-Contributors-Day-2012-Berlin -- ..Dan // Leinir.. http://leinir.dk/ Co- existence or no existence - Piet Hein ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Stepping down as the maintainer of QtWayland
Hi, I'm stepping down as the maintainer of QtWayland, as I don't have time to ensure that QtWayland is in top notch shape. I would like to propose Andy Nichols as the new maintainer. Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
tl;dr: d3fault if you keep up the good work you can join the security team the security team is for trustworthy individuals d3fault, we don't trust you How is my keeping up the good work earning trust? Do you guys really not see the gaping hole in that logic? d3fault ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
On Wed, Oct 24, 2012 at 11:55 AM, d3fault d3faultdot...@gmail.com wrote: tl;dr: How is my keeping up the good work earning trust? Do you guys really not see the gaping hole in that logic? I do certainly have problem trusting people that show that much interest in getting access to all vulnerabilities as you do. Especially if this person seems to argue for that thing just by iterating over the same statements again and again, using strange analogies trying to offend other people. Also I personally think it does not exactly help, if people keep using a strange pseudonym and seem to have a need to hide their real identity. To build a trust relationship, you certainly want to know, who you are talking to. Also you certainly do not want to trust people that offend you on a regular base. So, since we obviously will not agree on this topic in any the near future, let's finally conclude this thread and move on. There is a lot of meaningful work out there! Zeno d3fault ___ 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] New proposal for the tool naming
Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build You definitely don't want support multiarch configurations out-of-the-box :) Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5 /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86` (or even with `qmake -set-qt 5x86` if you created a symlink to the 5.0-x86's config file). And yeah, switching the system-default Qt for all users just to build some crappyhelloworldexample .pro is a shiny new great idea :) qmake -set… would/should/must certainly set a *user* specific default. (There'd need to be other mechanisms for distributors and admins to set the system wide default.) if we're talking about the new qmake wrapper, then yes, certainly. however, the system wide default Qt version could be set by the distributor easily with that qmake wrapper as well by simply replacing the default Qt version's config file somewhere at /etc/qmake (?) - they could even have some default symlink there that would point to the real config file of choice. so, if we're on multilib, thenthe distributor would point /etc/qmake/default to, say, qt5-unknown-linux-x86_64. such an ability makes the distributor's life easier whilst the system wide default version could be managed by the alternatives tools I know. on the other hand, having a /usr/bin/qmake5 symlink doesn't solve any issues on multilib - we still need /usr/bin/qmake5-x86 in this case. Konstantin 2012/10/24 Ziller Eike eike.zil...@digia.com: On 24 Oct 2012, at 08:04, Konstantin Ritt ritt...@gmail.com wrote: Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build You definitely don't want support multiarch configurations out-of-the-box :) Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5 /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86` (or even with `qmake -set-qt 5x86` if you created a symlink to the 5.0-x86's config file). And yeah, switching the system-default Qt for all users just to build some crappyhelloworldexample .pro is a shiny new great idea :) qmake -set… would/should/must certainly set a *user* specific default. (There'd need to be other mechanisms for distributors and admins to set the system wide default.) Konstantin 2012/10/24 Lincoln Ramsay a1291...@gmail.com: On 24/10/12 04:33, Thiago Macieira wrote: I think we are keeping it simple. The current proposal is the simplest that still works. If you can come up with something even simpler, I'll gladly accept it. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? Drop it. I know I complained about renaming qmake but... it would be simpler to rename qmake to qmake5 than to have a 'special' qmake that may or may not be the qmake that's first in your PATH and that may or may not do something with a -qtx switch. So I'm going to remove my +1 for the 'special' qmake and instead suggest a much simpler solution. This is just for 'qmake' though, everything else... same as it was before. Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build Optional: Create libexec/bin/qmake as a symlink to qmake5 (for Windows... a .bat or .cmd may work, else a copy). The officially supported way to build thus becomes qmake5 and it is guaranteed to work no matter what platform you're on or how you've set your PATH. Yes, we have to update all the documentation. The optional symlink is for complainers like me, so we can continue to run qmake - but only if we set PATH correctly first. It'll also help with old instructions, scripts, etc. that would break if we just renamed qmake ;) -- Link ___ 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 -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
Re: [Development] New proposal for the tool naming
On 24/10/12 4:04 PM, Konstantin Ritt wrote: You definitely don't want support multiarch configurations out-of-the-box :) Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5 /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86` (or even with `qmake -set-qt 5x86` if you created a symlink to the 5.0-x86's config file). And yeah, switching the system-default Qt for all users just to build some crappyhelloworldexample .pro is a shiny new great idea :) The original problem being solved is co-installation of Qt 4 + Qt 5 for Linux distros. How is any of the above relevant to that? If you want to solve all those other problems then sure, a symlink isn't enough but I'm not sure we need to solve all those other problems as part of the co-installation of Qt 4 + Qt 5 for Linux distros. You still have PATH, qset, etc. for selecting a specific build when there are multiple available. Work on this meta-qmake that calls through to one of many installed versions can still be done. Perhaps though, it's not something that needs to block the release of Qt 5.0. -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
Please disregard Zeno's personal attacks towards me and his request that the subject die and we all move on. His type of email is exactly what I describe two emails back. Waste (so is this one, except to keep the subject alive). If you can't say something relevant [to the argument], don't say nothin' at all. -Thumper d3fault ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
On 10/24/2012 11:30 AM, d3fault wrote: On 10/24/12, Samuel Rødal samuel.ro...@digia.com wrote: Lars and Charles both provided good lists of reasons in another part of this thread for going with the policy of Responsible Disclosure. Clearly you disagree on the weighting of the pros and cons, but it doesn't seem like you're able to convince anyone else about the superiority of your position. At what point will you accept that? dubtef' you're right, I completely missed Lars' response somehow :-/. I think I've logically proven a vulnerability exists within the Qt Security Policy. I think what I'm proposing is reasonable. It accommodates both responsible and full disclosure. Yes I can be an arsehole at times (triggered especially when I'm talked down to: let us make important decisions for you ... and basically this whole you have to trust us with your security mentality), but skipping over the argument completely and focusing only on my bad behavior is even worse than the bad behavior itself. As far as I see it all the options have vulnerabilities, so it shouldn't be hard to prove that they exist within either approach. If I get you correctly, you're saying that you want two security mailing lists, one open and one closed. Others have countered this by saying that the existing development mailing list will in practice act as the open one. In what way do you perceive these two options as being radically different? -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Stepping down as the maintainer of QtWayland
+1 I've overheard Andy in hallway conversations where he switched occasionally from English (accented) to the wayland protocol (1.0 final spec) and back. Simon -- Sendt fra min Nokia N924.10.12 12:03 skrev Paul Olav Tvete: On Wednesday 24 October 2012 11:51:09 Jørgen Lind wrote: I'm stepping down as the maintainer of QtWayland, as I don't have time to ensure that QtWayland is in top notch shape. I'm sad to hear that, but it's not completely unexpected. Thank you very much for all the brilliant work and enthusiasm you have put in to make QtWayland what it is today. I would like to propose Andy Nichols as the new maintainer. +1 from me; Andy has been the de facto maintainer for a while already. - Paul ___ 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] Stepping down as the maintainer of QtWayland
On 10/24/2012 05:50 PM, Hausmann Simon wrote: +1 I've overheard Andy in hallway conversations where he switched occasionally from English (accented) to the wayland protocol (1.0 final spec) and back. +1 from me as well :) -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android build
On 10/24/2012 12:16 PM, Łukasz Korbel wrote: Hello, I have build Qt5 Beta following instructions from http://qt-project.org/wiki/Android (with some small fixes for paths) I noticed that qt had built without QtDeclarative module, so I've built it manually. Its still not recognized as a module by qmake (Project ERROR: Unknown module(s) in QT: quick) but I can build qml project using appropriate INCLUDEPATH and LIBS vars. Still want to ask if there is the way to build QtDeclarative along with the rest of qt5 on Android so qmake will be aware of this module existence. You could try this approach: http://qt-project.org/wiki/Korhal -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android build
That is a mighty beautiful link On Wed, Oct 24, 2012 at 9:54 AM, Samuel Rødal samuel.ro...@digia.com wrote: On 10/24/2012 12:16 PM, Łukasz Korbel wrote: Hello, I have build Qt5 Beta following instructions from http://qt-project.org/wiki/Android (with some small fixes for paths) I noticed that qt had built without QtDeclarative module, so I've built it manually. Its still not recognized as a module by qmake (Project ERROR: Unknown module(s) in QT: quick) but I can build qml project using appropriate INCLUDEPATH and LIBS vars. Still want to ask if there is the way to build QtDeclarative along with the rest of qt5 on Android so qmake will be aware of this module existence. You could try this approach: http://qt-project.org/wiki/Korhal -- Samuel ___ 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] Stepping down as the maintainer of QtWayland
On Oct 24, 2012, at 5:59 PM, Samuel Rødal samuel.ro...@digia.com wrote: On 10/24/2012 05:50 PM, Hausmann Simon wrote: +1 I've overheard Andy in hallway conversations where he switched occasionally from English (accented) to the wayland protocol (1.0 final spec) and back. +1 from me as well :) And a +1 from me :) Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
On 10/24/12, Samuel Rødal samuel.ro...@digia.com wrote: As far as I see it all the options have vulnerabilities, so it shouldn't be hard to prove that they exist within either approach. Yep. Close one giant security-through-obscurity vulnerability, open the door for script kiddies. It's a trade off, but at least we won't have the ILLUSION OF SECURITY (worse than being insecure) anymore. If I get you correctly, you're saying that you want two security mailing lists, one open and one closed. Others have countered this by saying that the existing development mailing list will in practice act as the open one. In what way do you perceive these two options as being radically different? Knowledge availability, which I value and I guess others do not? m_ListOfUsersCommentingWithoutFirstReading Samuel; See: http://lists.qt-project.org/pipermail/development/2012-October/007478.html Duuude, you responded directly to that email too. How the what the I don't even Are you trolling me? d3fault ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QmlImportPath
Hi, we are still having problems with the QmlImportPath. There is also already a bug reported: https://bugreports.qt-project.org/browse/QTBUG- 20539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel https://bugreports.qt-project.org/browse/QTBUG- 20539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel Sounds pretty much like https://bugreports.qt-project.org/browse/QTBUG-17529 , or a variant of it. I don't know whether the patch I've proposed at https://codereview.qt-project.org/#change,33415 would help you though, since it fixes the problem only for absolute paths set to QtQUickView::setSource and QQmLEngine::setBaseUrl ... Actually I'm more than ever convinced that QML shouldn't check for file case sensitivity at all (on case insensitive file systems), or at least not in folder names. Feel free to vote. I believe that the problem is that (as Aaron states in that change request) if we don't enforce case-sensitivity, we get the unfortunate situation that an application which works on Windows, or Mac OS X, might not work on Linux. By enforcing case sensitivity, we ensure that the application works on all platforms without requiring any changes. In the past, we had heaps of bug reports about this exact issue, until we started enforcing case sensitivity on all platforms. I've added Martin Jones to that change request to get his opinion, but I would be surprised if changing this behaviour at this point in time is sensible. Cheers, Chris. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] On the reliability of CI
Replying here to some comments on IRC, since I'm rarely online at the same time as the others, but I don't want to let all the comments go unanswered... steveire [06:32:44] CI is seriously depresssing. For the last 24 hours there has been one successful merge. Many of the others are failing because of something in network. richmoore1 [06:40:03] steveire: a lot of this seems to be caused by the moving of the CI infrstructure to digia. it doesn't seem to be working fully yet I don't think that's true. As far as I know, the projects migrated to Digia have been working fine, and only the Nokia system (which has lost the majority of its support staff) has been having problems. The Nokia qt-test-server kernel recently started to produce kernel: [14564774.569761] swapper: page allocation failure. order:4, mode:0x4020 after 377 days uptime with few problems. I don't think this is directly related to any Nokia - Digia transition activities, rather an unfortunate coincidence of timing. ThorbjornTux [06:54:20] steveire: there was a discussion not that long ago in here ... I think that the conclusion were that tests that failed without reason was ok to be marked as insignificant (as you suggested). ThorbjornTux [06:54:47] steveire: the problem seems only to be if anybody does it .. steveire [06:55:10] Exactly. There used to be people who did things like that. True, there used to be Nokia employees reading every failure report and chasing up apparently unstable tests, either trying to fix the tests, or acknowledge them via bug reports and marking them insignificant. Those people are gone and the test results are likely to be less stable until they're replaced - either by more people doing the same job, or an automated solution to achieve stable test results from an unstable product. jpnurmi [07:30:23] steveire: np, those tests have been annoying me several times :) steveire [07:31:01] Yes. But why did I get so much pushback on fixing it? Something for qt-project to think about. sahumada [07:31:35] because you are not fixing it .. you are hiding it :) steveire [07:32:23] I'm fixing the problem that nothing has any chance of integrating. With your attitude, insignificant_test and QSKIP would not exist or be needed. I think it's great to have more people actively doing something about failing tests, as long as they take responsibility for their actions. The alternative of, when you see a flaky test, waiting for someone to do something, is not going to work (any more?) It might be good to have some guidelines about the best ways to handle flaky tests, since there are several options. torarne [09:18:47] anyone got powers to put things into qt5.git without the ci getting in the way? There's no built-in mechanism to bypass the system. We haven't needed one so far, we've always managed to handle problems as they arise. If it were an acceptable option to bypass the system when problems occur, it seems to me it would greatly reduce the incentive to fix the problems. steveire [10:34:22] Right. Anyone who can do anything doesn't really care. This is the kind of thing that should be fixable quickly The first part is false. I care, and I can do something - just not at the time you've reported the issue (although I was probably awake, I made a choice a while ago to minimize time spent fixing problems outside of normal working hours, because I felt it was burning me out). Actually, every CI failure which is not related to any of the changes under test slightly erodes my soul. I can guarantee I've been at least as frustrated as any users of the system, during its most unreliable times. The latter part is true and the problem was fixed quickly (for some subjective value of quickly), once it was known. richmoore1 [10:36:01] doing CI from one side of the world to the other is optimistic Yup, we used to have the Pulse server and all clients located together in Brisbane. The migration to Jenkins meant the server was moved to Europe. We have suffered a little bit from that. Luckily, this will soon be over; just a few more days and everything will be operating out of Europe. steveire [10:36:50] And yet, there's been no communication on the mailing list about the network problems (affecting everyone staging anything), despite the fact that it's been known since Monday at least. steveire [10:39:19] The insignification should have been done on Monday imo I didn't understand this part. There has been no known problem since Monday, this seems to be a false assumption. The specific network problem you're complaining about was reported to JIRA by you, last night at 9pm my time, and fixed by me within the first 30 minutes of my working day today. Reporting problems greatly increases the likelihood of a timely fix. You'll be able to get technical support within your own timezone once the transition to Digia completes. Please note that several days of instability doesn't imply
Re: [Development] On the reliability of CI
On 25/10/12 13:00, Rohan McGovern wrote: 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 This. The QA guys in Brisbane did an awesome job that was perhaps not so obvious or visible to people outside of the office. Not only did they keep the CI system running and stable, they poked, prodded and tweaked the Qt product so that it could pass through the CI system quickly (raising bugs as appropriate when tests were broken or flaky). I'm pretty sure there's someone at Digia ready to take over maintenance of the CI system. However, there isn't (to my knowledge) anyone ready to take on the task of keeping Qt in a state that can pass through the CI system. If nobody steps up to take on this responsibility then it'll fall on everyone to ensure their stuff is getting through CI. -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
