Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[Samuel Rødal]

On 10/24/2012 01:12 AM, d3fault wrote:
> On 10/23/12, Lincoln Ramsay  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

[Wehmer, Matthias]

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

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

[Ziller Eike]

On 23 Oct 2012, at 19:03, Thiago Macieira 
 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

[Ziller Eike]

On 24 Oct 2012, at 08:04, Konstantin Ritt 
 wrote:

>> Solution:
>> 
>> qmake renamed to qmake5 and lives with the other binaries in /bin
>> Create /usr/bin/qmake5 as a symlink to /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 :
>> 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 /bin
>> Create /usr/bin/qmake5 as a symlink to /bin/qmake5 for Linux
>> distro builds - triggered by some set of configure flags, NOT default
>> behaviour for a source build
>> 
>> Optional:
>> 
>> Create /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

[Koehne Kai]

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

[Jedrzej Nowacki]

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

[d3fault]

On 10/24/12, Samuel Rødal  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  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  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) Interruptions/noise 

Re: [Development] Updating "Serializing Qt Data Types" documentation

[Harri Porten]

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

[Dan Leinir Turthra Jensen]

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

[Jørgen Lind]

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

[d3fault]

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] Stepping down as the maintainer of QtWayland

[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

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[Zeno Albisser]

On Wed, Oct 24, 2012 at 11:55 AM, d3fault  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

[Development] Android build

[Łukasz Korbel]

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.

Thanks in advance,

*Łukasz Korbel*
Senior Software Developer

Milo Solutions
(+48) 517539562

http://milosolutions.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New proposal for the tool naming

[Konstantin Ritt]

>>> Solution:
>>>
>>> qmake renamed to qmake5 and lives with the other binaries in /bin
>>> Create /usr/bin/qmake5 as a symlink to /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 :
>
> On 24 Oct 2012, at 08:04, Konstantin Ritt 
>  wrote:
>
>>> Solution:
>>>
>>> qmake renamed to qmake5 and lives with the other binaries in /bin
>>> Create /usr/bin/qmake5 as a symlink to /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 :
>>> 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 /bin
>>> Create /usr/bin/qmake5 as a symlink to /bin/qmake5 for Linux
>>> distro builds - triggered by some set of configure flags, NOT default
>>> behaviour for a source build
>>>
>>> Optional:
>>>
>>> Create /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
> Ges

Re: [Development] New proposal for the tool naming

[Lincoln Ramsay]

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

[d3fault]

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

[Samuel Rødal]

On 10/24/2012 11:30 AM, d3fault wrote:
> On 10/24/12, Samuel Rødal  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

[Hausmann Simon]

+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

[Samuel Rødal]

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

[Samuel Rødal]

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

[Donald Carr]

That is a mighty beautiful link

On Wed, Oct 24, 2012 at 9:54 AM, Samuel Rødal  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

[Knoll Lars]

On Oct 24, 2012, at 5:59 PM, Samuel Rødal  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

[d3fault]

On 10/24/12, Samuel Rødal  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

[Chris Adams]

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

[Rohan McGovern]

Replying here to some comments on IRC, since I'm rarely online at the
same time as the others, but I don't want to let all the comments go
unanswered...

> steveire> [06:32:44] CI is seriously depresssing. For the last 24 hours
> there has been one successful merge. Many of the others are failing
> because of something in network.

> richmoore1> [06:40:03] steveire: a lot of this seems to be caused by the
> moving of the CI infrstructure to digia. it doesn't seem to be working
> fully yet

I don't think that's true.  As far as I know, the projects migrated to
Digia have been working fine, and only the Nokia system (which has lost
the majority of its support staff) has been having problems.

The Nokia qt-test-server kernel recently started to produce
"kernel: [14564774.569761] swapper: page allocation failure. order:4, 
mode:0x4020"
after 377 days uptime with few problems.  I don't think this is directly
related to any Nokia -> Digia transition activities, rather an
unfortunate coincidence of timing.

> ThorbjornTux> [06:54:20] steveire: there was a discussion not that long ago
> in here ... I think that the conclusion were that tests that failed without 
> reason
> was ok to be marked as insignificant  (as you suggested).
> ThorbjornTux> [06:54:47] steveire: the problem seems only to be if anybody 
> does it ..

> steveire> [06:55:10] Exactly. There used to be people who did things like 
> that.

True, there used to be Nokia employees reading every failure report and
chasing up apparently unstable tests, either trying to fix the tests, or
acknowledge them via bug reports and marking them insignificant.
Those people are gone and the test results are likely to be less stable
until they're replaced - either by more people doing the same job, or
an automated solution to achieve stable test results from an unstable
product.

> jpnurmi> [07:30:23] steveire: np, those tests have been annoying me several 
> times :)

> steveire> [07:31:01] Yes. But why did I get so much pushback on fixing it? 
> Something
> for qt-project to think about.

> sahumada> [07:31:35] because you are not fixing it .. you are hiding it :)

> steveire> [07:32:23] I'm fixing the problem that nothing has any chance of 
> integrating.
> With your attitude, insignificant_test and QSKIP would not exist or be needed.

I think it's great to have more people actively doing something about
failing tests, as long as they take responsibility for their actions.
The alternative of, when you see a flaky test, waiting for "someone" to
do something, is not going to work (any more?)

It might be good to have some guidelines about the best ways to handle
flaky tests, since there are several options.

> torarne> [09:18:47] anyone got powers to put things into qt5.git
> without the ci getting in the way?

There's no built-in mechanism to bypass the system.  We haven't needed
one so far, we've always managed to handle problems as they arise.
If it were an acceptable option to bypass the system when problems occur,
it seems to me it would greatly reduce the incentive to fix the
problems.

>  [10:34:22] Right. Anyone who can do anything doesn't really
> care. This is the kind of thing that should be fixable quickly

The first part is false.  I care, and I can do something - just not at
the time you've reported the issue (although I was probably awake, I
made a choice a while ago to minimize time spent fixing problems outside
of normal working hours, because I felt it was burning me out).

Actually, every CI failure which is not related to any of the changes
under test slightly erodes my soul.
I can guarantee I've been at least as frustrated as any users of the
system, during its most unreliable times.

The latter part is true and the problem was fixed quickly (for some
subjective value of "quickly"), once it was known.

> richmoore1> [10:36:01] doing CI from one side of the world to the other
> is optimistic

Yup, we used to have the Pulse server and all clients located together
in Brisbane.
The migration to Jenkins meant the server was moved to Europe.
We have suffered a little bit from that.
Luckily, this will soon be over; just a few more days and everything
will be operating out of Europe.

> steveire> [10:36:50] And yet, there's been no communication on the mailing
> list about the network problems (affecting everyone staging anything),
> despite the fact that it's been known since Monday at least.
>  [10:39:19] The insignification should have been done on
> Monday imo

I didn't understand this part.
There has been no known problem since Monday, this seems to be a false
assumption.
The specific network problem you're complaining about was reported to
JIRA by you, last night at 9pm my time, and fixed by me within the first
30 minutes of my working day today.
Reporting problems greatly increases the likelihood of a timely fix.

You'll be able to get technical support within your own timezone once
the transition to Digia completes.

Please note that severa

Re: [Development] On the reliability of CI

[Lincoln Ramsay]

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

Re: [Development] On the reliability of CI

[Turunen Tuukka]

On 25.10.2012 7.32, "Lincoln Ramsay"  wrote:

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

We have allocated some of our very best engineers to the CI transfer
project and will continue to do so. We are fully aware of the importance
of the CI system. Transferring the system is certainly a non-trivial tasks
and it has actually been proceeding really well. At the same time we are
also doing major improvements to the system architecture, which will allow
more collaboration than before.

Rest assured, we will do our very best to keep the system in good shape.
Digia is by far the biggest contributor to Qt and when there are problems
in the CI no-one hurts more than us. That said, it will take us a lot of
time and effort to get things running smoothly - and a lot of learning to
get even close to the competence level of the guys who have operated the
CI before.

Yours,

Tuukka

___
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

[Knoll Lars]

Let's close this topic. It's not always the one who shouts loudest that wins an 
argument.

We have a closed security mailing list, and I want to keep it that way. That 
seems to also be in agreement with the majority of the maintainers who have 
been dealing with this topic.

The members of the security list will work hard to keep response time and time 
to full disclosure at a minimum.

We have an open development mailing list for everything else, as many people 
have pointed out.

Cheers,
Lars

On Oct 25, 2012, at 1:22 AM, d3fault 
 wrote:

> Made a chart so people who don't want to read this whole thread don't have to.
> 
> Impenetrable logic.
> http://bayfiles.com/file/p3vn/E41lwK/Full.vs.Responsible.Disclosure.Chart.png
> 
> 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