Re: [Development] [Releasing] Can we do a last minute upgrade of the MinGW toolchain?
Hi, We decided yesterday in the release team meeting to do an upgrade of the MinGW toolchain. That is, the MinGW toolchain we'll be testing releasing with is http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/32-bit/threads-posix/sjlj/x32-4.7.2-release-posix-sjlj-rev8.7z/download (This is basically the same configuration we've had before, just rev8 instead of rev1). Other mingw toolchains _might_ work of course too. Anyhow, if you just want to go with the mainstream you should probably use the above. For a 64 bit toolchain I suggest to use http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/64-bit/threads-posix/sjlj/x64-4.7.2-release-posix-sjlj-rev8.7z/download However, we're concentrating efforts on 32 bit for now. Regards Kai -Original Message- From: releasing-bounces+kai.koehne=digia@qt-project.org [mailto:releasing-bounces+kai.koehne=digia@qt-project.org] On Behalf Of Koehne Kai Sent: Monday, January 21, 2013 2:21 PM To: Anttila Janne; releas...@qt-project.org Cc: Poenitz Andre Subject: Re: [Releasing] Can we do a last minute upgrade of the MinGW toolchain? Hi, I'd like to update my suggestion to http://sourceforge.net/projects/mingwbuilds/files/host- windows/releases/4.7.2/32-bit/threads-win32/sjlj/x32-4.7.2-release-win32- sjlj-rev8.7z/download Reasons: - rev8 contains fixes e.g. for gdb, as well as general small fixes [1] - win32 threading library (vs posix one) is considered faster and more reliable [2] On the other side, there's no hard reason (like XY not compiling) to switch. I think this should be therefore discussed on the release team meeting. Personally I don't expect big problems either to upgrade anyway if we decide to do it _now_. [1]: Change Log http://sourceforge.net/projects/mingwbuilds/files/host- windows/releases/4.7.2/32-bit/threads-win32/sjlj/ [2]: I'll leave the final decision up to you, but for stability's sake I'd suggest using plain win32 threading (Qt is used by a lot of people and it'd suck for people to have a bad MinGW-w64 experience with it). http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/6744 -Original Message- From: Anttila Janne Sent: Thursday, January 17, 2013 2:35 PM To: Koehne Kai; releas...@qt-project.org Cc: net...@gmail.com; Poenitz Andre Subject: RE: Can we do a last minute upgrade of the MinGW toolchain? [...] The problem is that CI machines are controlled by puppet and before doing (re)installation it does check that if correct version of MinGW is already installed. At the moment puppet configuration for MinGW is configured to execute 'gcc.exe --version', which returns: --- gcc.exe (Built by MinGW-builds project) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. --- You could use gcc.exe -v , though that might be already too verbose :) Regards Kai ___ Releasing mailing list releas...@qt-project.org http://lists.qt-project.org/mailman/listinfo/releasing ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtMultimedia BIC / header cleanliness issue
On Tuesday, January 22, 2013 11:40:23 AM Oswald Buddenhagen wrote: On Mon, Jan 21, 2013 at 08:14:03AM -0800, Thiago Macieira wrote: On segunda-feira, 21 de janeiro de 2013 15.33.59, Knoll Lars wrote: Finally reading up on some old emails… I'd say we add the virtual destructors. Better to deal with the fallout now then in the future. And rename the libraries to libQt5Multimedia.so.6 ? imo no. just pretend that it never happened. at this point there aren't many packages which are considered stable, and even fewer packages which depend on this module. other users won't be affected by this change to any noteworthy degree. however, make sure this gets into 5.0.1, which means bugging the release team at this point, very soon. That seems most reasonable to me. It's not perfect-by-the-book, but I also don't think anyone would notice it given the release just in december. (famous last words!) Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Help needed with failing test: tst_qaccessibility::bridgeTest() on Windows
Hi David. Yes, I can take a look. Do you know if it's unstable, or is it failing all the time? Jan Arve -Original Message- From: David Faure [mailto:david.fa...@kdab.com] Sent: 16. januar 2013 14:14 To: Kleint Friedemann; Saether Jan-Arve Cc: development@qt-project.org Subject: Help needed with failing test: tst_qaccessibility::bridgeTest() on Windows Hi Jan Arve, This test has failed the last 3 times I've been trying to merge an unrelated change to qtbase, and I remember seeing similar failures before too. Autotest `tst_qaccessibility' failed :( Testing tst_QAccessibility QtQA::App::TestRunner: Process exited with exit code 0xC005 (STATUS_ACCESS_VIOLATION) QtQA::App::TestRunner: test failed, running again to see if it is flaky... * Start testing of tst_QAccessibility * Config: Using QTest library 5.1.0, Qt 5.1.0 PASS : tst_QAccessibility::initTestCase() [...] PASS : tst_QAccessibility::accelerators() QtQA::App::TestRunner: Process exited with exit code 0xC005 (STATUS_ACCESS_VIOLATION) QtQA::App::TestRunner: test failure could be reproduced twice consecutively QtQA::App::TestRunner: end tst_qaccessibility: 13 seconds, exit code 3221225477 Build log: http://testresults.qt- project.org/ci/QtBase_dev_Integration/build_00101/win32- msvc2010_Windows_7/log.txt.gz The next method is bridgeTest(), which is a Windows-specific test. Could you take a look? Thanks. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Help needed with failing test: tst_qaccessibility::bridgeTest() on Windows
Ah thanks! And sorry for the noise. -Original Message- From: Gladhorn Frederik Sent: 16. januar 2013 15:57 To: development@qt-project.org Cc: David Faure; Kleint Friedemann; Saether Jan-Arve Subject: Re: [Development] Help needed with failing test: tst_qaccessibility::bridgeTest() on Windows Hi David, Onsdag 16. januar 2013 14.13.43 skrev David Faure: Hi Jan Arve, This test has failed the last 3 times I've been trying to merge an unrelated change to qtbase, and I remember seeing similar failures before too. Autotest `tst_qaccessibility' failed :( Testing tst_QAccessibility QtQA::App::TestRunner: Process exited with exit code 0xC005 (STATUS_ACCESS_VIOLATION) QtQA::App::TestRunner: test failed, running again to see if it is flaky... * Start testing of tst_QAccessibility * Config: Using QTest library 5.1.0, Qt 5.1.0 PASS : tst_QAccessibility::initTestCase() [...] PASS : tst_QAccessibility::accelerators() QtQA::App::TestRunner: Process exited with exit code 0xC005 (STATUS_ACCESS_VIOLATION) QtQA::App::TestRunner: test failure could be reproduced twice consecutively QtQA::App::TestRunner: end tst_qaccessibility: 13 seconds, exit code 3221225477 Build log: http://testresults.qt- project.org/ci/QtBase_dev_Integration/build_00101/win32- msvc2010_Windows_7/log.txt.gz The next method is bridgeTest(), which is a Windows-specific test. Could you take a look? Thanks. Friedemann fixed the issue (in the release branch) so it took some time to trickle into stable and will hopefully make it to dev as well now. (fix) https://codereview.qt-project.org/#change,44856 (release-stable) https://codereview.qt-project.org/#change,44901 (stable-dev) https://codereview.qt-project.org/#change,44924 Greetings Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLogs
On 1/21/13 17:14 , Thiago Macieira wrote: On segunda-feira, 21 de janeiro de 2013 17.02.10, Tor Arne Vestbø wrote: On 1/21/13 16:37 , Giuseppe D'Angelo wrote: On 21 January 2013 15:08, Tor Arne Vestbø tor.arne.ves...@digia.com wrote: If you're writing the ChangeLog entry at commit time, not right before the release, why can't your patch contain a change to dist/changelog from the get-go which, can be reviewed and integrated along with the code change? Because that usually causes silly conflicts when staging (=merging) the patch. :( That can be solved by a git merge-driver for the changelog format. Note: the merging is done by Gerrit. Hmm, and it doesn't support merge-drivers as far as I can tell :( But isn't the merging done by the CI using regular Git by cherry-picking into the staging branch, and then integration is a fast-forward? tor arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtMultimedia BIC / header cleanliness issue
On Tuesday, January 22, 2013 11:40:23 AM Oswald Buddenhagen wrote: On Mon, Jan 21, 2013 at 08:14:03AM -0800, Thiago Macieira wrote: On segunda-feira, 21 de janeiro de 2013 15.33.59, Knoll Lars wrote: Finally reading up on some old emails… I'd say we add the virtual destructors. Better to deal with the fallout now then in the future. And rename the libraries to libQt5Multimedia.so.6 ? imo no. just pretend that it never happened. at this point there aren't many packages which are considered stable, and even fewer packages which depend on this module. other users won't be affected by this change to any noteworthy degree. however, make sure this gets into 5.0.1, which means bugging the release team at this point, very soon. That seems most reasonable to me. It's not perfect-by-the-book, but I also don't think anyone would notice it given the release just in december. (famous last words!) I don't think it should be done silently at all, I'm not exactly for the idea of even breaking BC but I can accept an exception this early in the Qt 5.x series if there is no other way and it is critical to be done. But this should be clear in the changelog and release notes that it was done, better to be open about it than to hope no-one notices. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [semi-solved] Qt5 moc error in combination with boost
There's a Qt5 moc error when using Boost, with a work-around. See: http://qt-project.org/forums/viewthread/22993 It describes Boost 1.49, but this work-around also works for Boost 1.52: ...leads to compile error (Win7/MSVS2010): C:/Some/Path/3rd/Boost/boost_1_52_0/boost/mpl/if.hpp(131): Error: Macro argument mismatch. Project : error PRJ0019: A tool returned an error code from MOC ..\..\Some\Path\MyClass.hpp Work-around, in ALL files that moc: //...USING BOOST, MUST GUARD INCLUSION... #ifndef Q_MOC_RUN # include boost/function.hpp # include MyClass.hpp #endif // Q_MOC_RUN We're not using much of Boost 1.52, but we *do* use some of the type/traits stuff (which triggers this error). There are a few Boost/moc errors/bugs reported in https://bugreports.qt-project.org/, but I couldn't find this one. Did I miss it, or should I create a new one? I'm specifically curious about when this might be fixed, as the work-around is annoying (I haven't looked into what the fix might be). Thanks! --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtMultimedia BIC / header cleanliness issue
-Original Message- On Tuesday, January 22, 2013 11:40:23 AM Oswald Buddenhagen wrote: On Mon, Jan 21, 2013 at 08:14:03AM -0800, Thiago Macieira wrote: On segunda-feira, 21 de janeiro de 2013 15.33.59, Knoll Lars wrote: Finally reading up on some old emails… I'd say we add the virtual destructors. Better to deal with the fallout now then in the future. And rename the libraries to libQt5Multimedia.so.6 ? imo no. just pretend that it never happened. at this point there aren't many packages which are considered stable, and even fewer packages which depend on this module. other users won't be affected by this change to any noteworthy degree. however, make sure this gets into 5.0.1, which means bugging the release team at this point, very soon. That seems most reasonable to me. It's not perfect-by-the-book, but I also don't think anyone would notice it given the release just in december. (famous last words!) I don't think it should be done silently at all, I'm not exactly for the idea of even breaking BC but I can accept an exception this early in the Qt 5.x series if there is no other way and it is critical to be done. But this should be clear in the changelog and release notes that it was done, better to be open about it than to hope no-one notices. I must say I agree with Andy here. Especially as we are actually doing this development in the open. As anyone can watch us, we are setting a standard for how SW development is done, and Qt has had a high star as far as SW quality goes. This is the reason many people choose Qt. And I think that is goes without saying, even though not many people are likely to be using it, that especially as we do something out of the ordinary we need to properly document it. Anything else would be rude. Best regards Nils Christian Roscher-Nielsen – Digia, Qt ___ 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] QtMultimedia BIC / header cleanliness issue
On Tue, Jan 22, 2013 at 02:29:53PM +0100, Shaw Andy wrote: On Tuesday, January 22, 2013 11:40:23 AM Oswald Buddenhagen wrote: imo no. just pretend that it never happened. at this point there aren't many packages which are considered stable, and even fewer packages which depend on this module. other users won't be affected by this change to any noteworthy degree. That seems most reasonable to me. It's not perfect-by-the-book, but I also don't think anyone would notice it given the release just in december. I don't think it should be done silently at all, I'm not exactly for the idea of even breaking BC but I can accept an exception this early in the Qt 5.x series if there is no other way and it is critical to be done. But this should be clear in the changelog and release notes that it was done, better to be open about it than to hope no-one notices. this isn't about a cover-up, but about not making a fuss about a virtual non-event (no pun intended). changelog entries, etc. are ok (like for any bugfix), while changing the soversion seems just a bit over the top. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ChangeLogs
On Tue, Jan 22, 2013 at 02:18:46PM +0100, Tor Arne Vestbø wrote: But isn't the merging done by the CI using regular Git by cherry-picking the merging is done by gerrit itself, as you can (more or less) see when you hit the stage button. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [semi-solved] Qt5 moc error in combination with boost
On Tuesday 22 January 2013 06:32:45 Charley Bay wrote: There's a Qt5 moc error when using Boost, with a work-around. See: http://qt-project.org/forums/viewthread/22993 It describes Boost 1.49, but this work-around also works for Boost 1.52: ...leads to compile error (Win7/MSVS2010): C:/Some/Path/3rd/Boost/boost_1_52_0/boost/mpl/if.hpp(131): Error: Macro argument mismatch. Project : error PRJ0019: A tool returned an error code from MOC ..\..\Some\Path\MyClass.hpp Work-around, in ALL files that moc: //...USING BOOST, MUST GUARD INCLUSION... #ifndef Q_MOC_RUN # include boost/function.hpp # include MyClass.hpp #endif // Q_MOC_RUN We're not using much of Boost 1.52, but we *do* use some of the type/traits stuff (which triggers this error). There are a few Boost/moc errors/bugs reported in https://bugreports.qt-project.org/, but I couldn't find this one. Did I miss it, or should I create a new one? I'm specifically curious about when this might be fixed, as the work-around is annoying (I haven't looked into what the fix might be). Thanks! --charley I have boost 1.50 here and I cannot reproduce the issue. Please open a new bug report and if possible, a small test-case that does not depends on boost. Try to copy all the involved macro in a file. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving Qt 4 mobility and qt-labs to gerrit
Hello, We are now generating the documentation in the 'master' branch of the Qt Mobility repository at doc-snapshot.qt-project.org: http://doc-snapshot.qt-project.org/ It is built using Qt 4.8 and is built daily. There is activity in the repository (and JIRA) and there are still people who use the Qt Mobility documentation. I updated the HTML copyright header to match the Qt Project copyright notice. The other copyrights notices remain and I'll leave it to the maintainers or the community to update the repository. Cheers, Jerome P. Documentation Engineer - Digia, Qt Fra: development-bounces+jerome.pasion=digia@qt-project.org [development-bounces+jerome.pasion=digia@qt-project.org] p#229; vegne av Lorn Potter [lorn.pot...@gmail.com] Sendt: 3. november 2012 02:16 To: development@qt-project.org Emne: Re: [Development] Moving Qt 4 mobility and qt-labs to gerrit On 01/11/12 19:45, Sergio Ahumada wrote: Hi, On 11/01/2012 09:02 AM, Knoll Lars wrote: Hi everybody, this is mainly a heads up for all of you. As part of the transfer from Nokia to Digia, we've also inherited the rights to Qt mobility (4.x), as well as the content of qt-labs (http://qt.gitorious.org/qt-labs/). We want to start moving these projects over to gerrit/codereview in the next days, so that they have a new home where people can contribute to them again (the gitorious mainlines are read-only currently). Qt Mobility has been moved to Gerrit (branches: 1.0, 1.1 and master) https://codereview.qt-project.org/#admin,project,qt-mobility/qt-mobility,info Note that Qt Mobility is not CI tested so please be careful with what you submit. I noticed that all the copyright headers in qt-mobility repo are currently most likely wrong, and mention Nokia. Just as a test, you can review this minor change https://codereview.qt-project.org/38589 Happy hacking ! Cheers, -- Lorn Potter Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo ___ 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] CI doing merge release-stable-dev
Tirsdag 22. januar 2013 07.14.01 skrev Fält Simo: Hi, I've been getting requests from several fronts to make ci to handle merge's between branches. Having automated merge from dev-stable-release doesn't make sense. But merging from release-stable-dev might be doable, but before doing that I would like to hear your input. It obviously only makes sense in the direction you indicated. As one of the people pushing for that, here is why: The longer we wait in detecting merge conflicts, the more tedious and error prone the merges become. Solving one or two conflicts is not big deal usually, but the more it gets the more error prone (I messed up simple stuff in my first qtbase attempts because there were around 20 different conflicts and at some point my concentration was gone). The merges when resolving cleanly should still be CI tested, we had one merge in declarative where the merge was clean but in the end a test failed since it was changed in a different place in dev than in stable and together it didn't work. This will help detect problems early which is a good thing. When there is a merge conflict, someone needs to manually resolve it - that means creating and pushing a merge commit. I think for Qt 4.x this was in place and worked quite nicely. Some people (Olivier and Thiago?) still spent quite some time resolving the merges. Once you know git well enough it's not a big pain any more though. At the moment, automated merge would always face a merge conflict due to sync.profile pointing to same branch where it currently is. To get this sorted out, we would have to leave the sync.profile to serve only one branch and let the others being hard coded to same branch as the module being tested. Currently it kind of behaves like this already, while I think sync.profile in each branch is picking the dependencies from same branch. But is this ok for developers, is that how you like it to behave? If it is, which branch should keep obeying the sync.profile and which ones we can hard code? No, as Thiago said, this is done once, git records that the commit changing the sync.profile is merged in a certain way. After that it will only be a problem when changing sync.profile again. When I now do a merge stable-dev I don't have to worry about sync.profile any more, it'll just be a conflict when merging for the first time. Greetings Frederik Simo Fält Digia, Qt Visit us on: http://qt.digia.comhttp://qt.digia.com/ -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtMultimedia BIC / header cleanliness issue
On terça-feira, 22 de janeiro de 2013 11.40.23, Oswald Buddenhagen wrote: I'd say we add the virtual destructors. Better to deal with the fallout now then in the future. And rename the libraries to libQt5Multimedia.so.6 ? imo no. just pretend that it never happened. Sune, especially for you: will you try and patch Qt to change the soname if we don't do it? -- 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] Qt 5.0.1 -- Release Testing
There isn't the mingw x64 package? Il giorno lun, 21/01/2013 alle 14.06 +0200, Iikka Eklund ha scritto: On 01/18/2013 03:37 PM, Motyka Rafal wrote: Hello, Qt 5.0.1 release testing has been started. We would like to kindly ask the Qt Community for help by testing the new packages. 1. Installer packages are available here: http://releases.qt-project.org/digia/5.0.1/backups/2013-01-18-412/ Please note that old backups will get deleted regularly. To get the latest one the following link can be used: http://releases.qt-project.org/digia/5.0.1/latest/ - iikka 2. Qt bug reports should be reported in JIRA: https://bugreports.qt-project.org/ Thank you. Best regards, /Rafal Rafal Motyka QE Engineer Digia, Qt Email: rafal.mot...@digia.com mailto:forename.surn...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qt Qt Twitter: 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.0.1 -- Release Testing
There isn't the mingw x64 package? No. I think that the idea is to get at least the 32 bit package to work and the 64 bit package in some future release. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Error while compiling WebKit QT 5.0.1
Hi all, i have this error while Compiling qtwebkit (QT 5.0.1) with mingw64_x64: (set PATH=C:\Development\qt-everywhere-opensource-src-5.0.1_mingw64 qtbase\..\gnuwin32\bin;%PATH%) python C:/Development/qt-everywhere-opensource-src-5.0.1_mingw64/qtwebkit/Source/WebCore/inspector/generate-inspector-protocol-version -o generated\InspectorProtocolVersion.h inspector\Inspector.json Self-test failedmake[2]: *** [generated/InspectorProtocolVersion.h] Error 1 make[2]: Leaving directory `C:/Development/qt-everywhere-opensource-src-5.0.1_mingw64/qtwebkit/Source/WebCore' make[1]: *** [sub-DerivedSources-pri-make_first-ordered] Error 2 make[1]: Leaving directory `C:/Development/qt-everywhere-opensource-src-5.0.1_mingw64/qtwebkit/Source/WebCore' make: *** [sub-Source-WebCore-WebCore-pro-make_first-ordered] Error 2 Tested with Windows 8 and Windows 7 @64bit ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [semi-solved] Qt5 moc error in combination with boost
Am 22.01.2013 14:58, schrieb Olivier Goffart: On Tuesday 22 January 2013 06:32:45 Charley Bay wrote: There's a Qt5 moc error when using Boost, with a work-around. See: http://qt-project.org/forums/viewthread/22993 It describes Boost 1.49, but this work-around also works for Boost 1.52: ...leads to compile error (Win7/MSVS2010): C:/Some/Path/3rd/Boost/boost_1_52_0/boost/mpl/if.hpp(131): Error: Macro argument mismatch. Project : error PRJ0019: A tool returned an error code from MOC ..\..\Some\Path\MyClass.hpp Work-around, in ALL files that moc: //...USING BOOST, MUST GUARD INCLUSION... #ifndef Q_MOC_RUN # include boost/function.hpp # include MyClass.hpp #endif // Q_MOC_RUN We're not using much of Boost 1.52, but we *do* use some of the type/traits stuff (which triggers this error). There are a few Boost/moc errors/bugs reported in https://bugreports.qt-project.org/, but I couldn't find this one. Did I miss it, or should I create a new one? I'm specifically curious about when this might be fixed, as the work-around is annoying (I haven't looked into what the fix might be). Thanks! --charley I have boost 1.50 here and I cannot reproduce the issue. Please open a new bug report and if possible, a small test-case that does not depends on boost. Try to copy all the involved macro in a file. I have maybe the same/similiar error (qt5.0, boost 1.52). After including #includeboost/uuid/uuid.hpp #include boost/uuid/random_generator.hpp in a qt-header file, I get the error boost/mpl/if.hpp(131): Error: Macro argument mismatch. during compiling of the correspondence moc_...cpp file. It looks like a preprocessor error message... Cheers Jan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Error while compiling WebKit QT 5.0.1
On terça-feira, 22 de janeiro de 2013 19.47.10, Carlo A. Scarpato wrote: (set PATH=C:\Development\qt-everywhere-opensource-src-5.0.1_mingw64 qtbase\..\gnuwin32\bin;%PATH%) python C:/Development/qt-everywhere-opensource-src-5.0.1_mingw64/qtwebkit/Source/We bCore/inspector/generate-inspector-protocol-version -o generated\InspectorProtocolVersion.h inspector\Inspector.json Self-test failed Looks like the script failed. Maybe it's a conflict with your Python version. Can you try upgrading or another build? -- 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
[Development] Full Ministro in Ministro-Redirection stub; WAS: Android port - Why do we need Ministro?
##Bringing this to development mailing list
- Original Message -
From: d3fault d3faultdot...@gmail.com
To: bog_dan...@yahoo.com
Cc:
Sent: Wednesday, January 16, 2013 7:53 AM
Subject: Full Ministro in Ministro-Redirection stub
Hi, sorry to bother you as I'm sure you're busy working on Android Qt,
but I'm wondering if maybe you didn't see my post here:
http://lists.qt-project.org/pipermail/development/2013-January/009249.html
on the topic of [Development] Android port - Why do we need
Ministro?. I understand the technical problem of no common shared
folder that Ministro solves and I'm wondering if there's a problem
with the design in my link (solves the same problem) that I'm just
failing to see? I like what Ministro does but I think making the
experience as seamless as possible (aka, they don't ever see or
explicitly install Ministro) would be the best solution for the end
users.
Also be sure to click to the next email in the thread for the DUH
solution to the bandwidth problem.
I am aware of the 2 new cons introduced by my design: each/every Qt
Android application now requires access to the SD-Card and the Network
(security risks), but I think they're worth it in the end because
Android is not a secure OS to begin with, as it includes proprietary
and closed source binaries (I'm willing to bet our views on security
differ).
Thank you for all of your contributions to Necessitas/Ministro/Qt,
d3fault
On Wed, Jan 16, 2013 at 10:52 AM, BogDan bog_dan...@yahoo.com wrote:
Hi,
Your solution sound similar with this
https://groups.google.com/group/android-qt/browse_thread/thread/708d0be52dd4af92
one.
Please check that thread for my answer.
Cheers,
BogDan.
Hmm, you're right, the design is flawed.
I've been letting the problem soak in my subconscious for the past
week or so and came up with a solution that I'm not sure you'll like.
Basically it's a compromise between:
a) Not trusting other applications to supply and/or not change the
libraries (because as you pointed out, md5 summing for integrity and
loading of libraries is not an atomic process)
b) Not caring about security because Android is already insecure
(proprietary binaries): as long as it is *FUNCTIONAL*, security can be
assumed to already be compromised so who really cares as long as it
works
Here's a solution that implements the compromise:
tl;dr: 2 Activities in the manifest. One for
'idgaf'/insecure/FUNCTIONAL usage, and one for
forced-loading-of-local/verified-and-non-outside-writeable-libraries/safer
usage
In Launcher:
1-ActivityRegular: Checks local dir for libs, broadcasts for libs
path (uses them if found), downloads libs if necessary, caches them on
SD card, md5sums local copy that is actually loaded
2-ActivityForcedSafer: Checks local dir for libs, DOES NOT BROADCAST
FOR LIBS PATH, downloads libs if necessary (or pulls from SD card
cache), caches them on SD card if relevant, md5sums local copy that is
actually loaded
Pros: Completely transparent/seamless to end users (the biggest pro of
them all), still provides 'moderate' security for those who actually
trust proprietary binaries (ROFLMFAO)
Cons: A pretty hefty amount of wasted disk space for every app that is
run even once in 'safer' mode (it would be possible/easy to run out of
space by running them all in Safer mode), cluttering of Launcher menu
(two entries for every one activity), all Qt-Android apps would need
Internet and SD Card Permissions
Even though the first con is a pretty big one, I think it's worth it
in order to provide a seamless Qt-Android user experience. I myself
will launch every app in 1-ActivityRegular mode, so the first con will
be invisible to me. I think most users will too because Android is not
a secure OS to begin with. Be that as it may, we should still provide
an as secure as Ministro [currently] mode of operation for those who
want it.
Additionally, knowledge of the underlying system/design allows you to
choose which Qt-Android application will be the one in charge
('trusted', just as Ministro needs to be trusted) of supplying the
libs: whichever one you install first.
d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] About QDeclarativeImageProvider.
//requestImage How I can call this method using threads. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cannot compile QT4.8.4 with nmake Linker error
Hi Peter, Thanks it worked:-) Linker error was resolved. Regards, Amogh. On Tue, Jan 22, 2013 at 1:37 PM, Peter Kümmel syntheti...@gmx.net wrote: Try without -no-iconv, the error is related to unicode stuff. On 22.01.2013 08:50, Amogh Kudari wrote: Hi Thiago, Thanks for your quick response. Now I reconfigured without -qpa option but *still I am getting the same errors.* Now configuration looks something like this... ConfigureOption= configure.exe -debug -opensource -confirm-license -little-endian -no-accessibility -no-stl -no-sql-sqlite -no-qt3support -no-nis -no-cups -no-iconv -no-3dnow -no-openssl -no-dbus -no-phonon -no-xmlpatterns -no-multimedia -no-script -no-scripttools -no-declarative -no-exceptions -nomake tests -nomake examples -nomake demos -webkit-debug ConfigureOption= Any suggestions... Regards, Amogh. On Tue, Jan 22, 2013 at 12:06 PM, Thiago Macieira thiago.macie...@intel.com mailto:thiago.macie...@intel.com wrote: On terça-feira, 22 de janeiro de 2013 11.46.28, Amogh Kudari wrote: I am compiling QT-4.8.4 with the following configure options on Windows(Using Visual Studio 2008 command prompt). =Configure === configure.exe -debug -opensource -little-endian -no-accessibility -no-stl -no-sql-sqlite -no-qt3support -no-nis -no-cups -no-iconv -no-largefile -no-3dnow -no-gtkstyle -no-openssl -no-dbus -no-phonon -no-xmlpatterns -no-svg -no-multimedia -no-script -no-scripttools -no-declarative -no-exceptions -nomake tests -nomake examples -nomake demos -qpa -webkit-debug Drop the -qpa argument. We told you before that QPA on Windows on Qt 4 is entirely unsupported and plainly does not work. You have now confirmed what we told you: the QPA code works on Unix systems only. -- Thiago Macieira - thiago.macieira (AT) intel.com http://intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org mailto: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 ___ 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
[Development] Cleaner code base patches
I've just pushed a set of patches for review that implement a more direct way of ensuring our codebase is cleaner (patches 45529 to 45533). You may have noticed, if I added you to one of my reviews in the past months, that I sent lots of fixes for warnings. If you paid attention to them, you may have noticed that they were all compiled with -Werror. Here's what my patches implement: 1) Qt library modules are compiled with -Werror (optional, via whitelist) I've implemented support for -Werror for both GCC and for Clang. I've also cleaned up all the warnings that I could find and were fixable for GCC 4.7 and Apple Clang (current). The idea is that we'll keep GCC 4.5 and up, Clang 3.1 and up, Apple Clang 4.0 and up clean of warnings. Modules declare that they are clean of warnings (and should be kept clean) by: CONFIG += qt_warnings_are_errors Possibly qualified by a compiler: *-g++*: CONFIG += qt_warnings_are_errors Additionally, it's possible to add some warning-disabling targets to the WERROR variable, for example: *-g++*|*-clang*: WERROR += -Wno-error=strict-aliasing Current status is that all qtbase libraries, qtsvg, qtxmlpatterns, qtquick1, qttools and qtimageformats compile with -Werror. qtscript will never compile with -Werror, qtwebkit manages this setting on its own, qtdeclarative currently has major strict-aliasing issues. 2) Direct compilation of all headers (mandatory) syncqt will generate a list of all public headers (not including the forwarding headers) and then we'll compile each header, directly, with -Werror and a few other settings, like QT_NO_KEYWORDS, QT_NO_CAST_FROM_ASCII, - Woverloaded-virtual, etc. This is a replacement for the existing tst_headers. Instead of compiling the headers all together, this will compile each header, one by one, and will catch mistakes like a header missing dependencies and or not compiling without precompiled headers. This is implemented now for GCC, Clang and ICC. This increases the build time by about 20%. I've also tested all modules and the only missing fix is the binary-compatibility one for qtmultimedia. Both features are enabled only if -developer-build is passed. -- 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
