Re: [Development] dev doesnt builds

2016-09-22 Thread Vlad Stelmahovsky 
In my desperate attempt to build it I even re-clone whole qt5 repo from
scratch. still doesnt works

On Thu, Sep 22, 2016 at 4:37 PM, Alexander Blasche 
wrote:

> Hi
>
> >Cannot read .qt5/qtbase/src/corelib/qtcore-config.pri: No such file
> or directory
> >Cannot read .qt5/qtbase/src/gui/qtgui-config.pri: No such file or
> directory
> >Project ERROR: Could not find feature system-zlib.
> >Makefile:45: recipe for target 'sub-src-make_first' failed
> >make[1]: *** [sub-src-make_first] Error 3
> >make[1]: Leaving directory '../qt5/qtbase'
> >Makefile:78: recipe for target 'module-qtbase-make_first' failed
> >make: *** [module-qtbase-make_first] Error 2
>
> >is there a workaround for this?
>
>
> I had the same problem. Make sure that you have an up-to-date qt5.git
> checkout for dev as well. In combination with git clean the problem solved
> itself for me.
>
> --
> Alex
>



-- 
Best regards,
Vlad
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUuid documentation

2016-09-22 Thread Matthew Woehlke 
On 2016-09-08 05:35, Benjamin TERRIER wrote:
> As of Qt 5.7, QUuid::createUuid() documentation is:
> 
>> On any platform other than Windows, this function returns a new UUID with 
>> variant QUuid::DCE and version QUuid::Random. If the /dev/urandom device 
>> exists, then the numbers used to construct the UUID will be of cryptographic 
>> quality, which will make the UUID unique. Otherwise, the numbers of the UUID 
>> will be obtained from the local pseudo-random number generator (qrand(), 
>> which is seeded by qsrand()) which is usually not of cryptograhic quality, 
>> which means that the UUID can't be guaranteed to be unique.
>>
>> On a Windows platform, a GUID is generated, which almost certainly will be 
>> unique, on this or any other system, networked or not.
> 
> So according to this there are 3 kinds of UUID:
> - Generated by /dev/urandom
> - Generated by qrand()
> - Generated on Windows OS
> 
> The documentation states explicitly that the first type is unique and
> that the 2 last types are not unique.

There are three types. The first is "unique" (unqualified). The second
"can't be guaranteed to be unique" (and while not stated explicitly,
"probably won't be under particular, easily obtained circumstances" is
implied). The third "almost certainly will be unique".

You are lumping the second and third into "not unique", which is a
little strange given the difference in degree of "probably unique" that
applies, which I think is throwing people off. However, I take your
point that probably the first should have the same "almost certainly"
qualification as the third, vs. the apparently unqualified "will be"
assertion it has presently. FWIW, that seems to me like a reasonable
change to request. (If nothing else, the first and third are AFAIK
equally likely to either be or not be unique, so phrasing them similarly
makes sense.)

-- 
Matthew

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

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

2016-09-22 Thread André Pönitz 
On Thu, Sep 22, 2016 at 06:04:58AM +0200, Mathias Hasselmann wrote:
> Am 22.09.2016 um 00:58 schrieb André Pönitz:
> >On Wed, Sep 21, 2016 at 08:57:01AM +0200, Olivier Goffart wrote:
> >>>No, it's not. It's changing undefined behavior into defined
> >>>behavior.
> >>
> >>But in many case, we want to put something in a QVariant, and we
> >>never compare this variant.  Forbidding types that do not have an
> >>operator== to be in a QVariant might be to strict.
> >
> >Forbidding types without operator== in QVariants is not needed,
> >not even if one wanted to use associative container with
> >QVariants as keys.
> >
> >[Pseudocode]
> >
> >bool operator(QVariant(Foo) a, QVariant(Bar) b)
> >{
> >if Foo != Bar:
> >return false
> >if Foo has no operator==():
> >return true
> >return (Foo)a == (Foo)b
> >}
> >
> >establishes an equivalance relation by lumping all "uncomparable"
> >objects into a single equivalency class.
> 
> I rather was considering to return false.

There is not much of a choice. An equivalence relation is reflexive,
i.e. at least Foo(a) == Foo(a) must be true. Lacking the ability
to compare Foos, treating them all equal at least doesn't break the
relation.

> But indeed. Forcing all that types into a single equivalency class feels
> that unnatural, that users should notice that issue much quicker, than if
> we'd return false.
> 
> Would that be sufficient to warn Qt users, or would we also have to print
> a warning?

I don't have an opinion on that.

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

Re: [Development] Qt5 Bearer: broken PPP support

2016-09-22 Thread Alexander Smirnov 

On 09/22/2016 05:07 AM, Thiago Macieira wrote:

On quarta-feira, 21 de setembro de 2016 07:57:42 PDT Thiago Macieira wrote:

I'll fix it when I'm back home tonight.


https://codereview.qt-project.org/171756


This works for me!



It was quite simple.



--
With best regards,
Alexander Smirnov

ilbers GmbH
Baierbrunner Str. 28c
D-81379 München
+49 (89) 122 67 24-0
http://ilbers.de/
Commercial register Munich, HRB 214197
General manager: Baurzhan Ismagulov
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] dev doesnt builds

2016-09-22 Thread Alexander Blasche 
Hi

>Cannot read .qt5/qtbase/src/corelib/qtcore-config.pri: No such file or 
>directory
>Cannot read .qt5/qtbase/src/gui/qtgui-config.pri: No such file or directory
>Project ERROR: Could not find feature system-zlib.
>Makefile:45: recipe for target 'sub-src-make_first' failed
>make[1]: *** [sub-src-make_first] Error 3
>make[1]: Leaving directory '../qt5/qtbase'
>Makefile:78: recipe for target 'module-qtbase-make_first' failed
>make: *** [module-qtbase-make_first] Error 2

>is there a workaround for this?


I had the same problem. Make sure that you have an up-to-date qt5.git checkout 
for dev as well. In combination with git clean the problem solved itself for me.

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

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-22 Thread Edward Welbourne 
On Thursday 22 September 2016 08:55:13 Liang Qi wrote:
>> Give the merge permission to everyone is obiviously not a solution.
Marc Mutz replied:
> Not everyone, but approvers, maybe? Merges need to be reviewed like
> any other commit, so why are they special, anyway?

Do we at least give all maintainers merge powers in their modules ?

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

Re: [Development] dev doesnt builds

2016-09-22 Thread Liang Qi 
On 22 September 2016 at 13:17, Vlad Stelmahovsky  wrote:

> Hi
>
> trying build dev branch and got this error all the time:
>
>
> Cannot read .qt5/qtbase/src/corelib/qtcore-config.pri: No such file
> or directory
> Cannot read .qt5/qtbase/src/gui/qtgui-config.pri: No such file or
> directory
> Project ERROR: Could not find feature system-zlib.
> Makefile:45: recipe for target 'sub-src-make_first' failed
> make[1]: *** [sub-src-make_first] Error 3
> make[1]: Leaving directory '../qt5/qtbase'
> Makefile:78: recipe for target 'module-qtbase-make_first' failed
> make: *** [module-qtbase-make_first] Error 2
>
>
> is there a workaround for this?
>

Perhaps missing a qt5 5.8->dev merge to include
https://github.com/qt/qt5/commit/64cc947ded527197168f5d16f25a15638e58 .

Anyway, the dev branch for all modules except qtbase are blocked by
https://bugreports.qt.io/browse/QTBUG-56122 .

Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] dev doesnt builds

2016-09-22 Thread Vlad Stelmahovsky 
Hi

trying build dev branch and got this error all the time:


Cannot read .qt5/qtbase/src/corelib/qtcore-config.pri: No such file or
directory
Cannot read .qt5/qtbase/src/gui/qtgui-config.pri: No such file or
directory
Project ERROR: Could not find feature system-zlib.
Makefile:45: recipe for target 'sub-src-make_first' failed
make[1]: *** [sub-src-make_first] Error 3
make[1]: Leaving directory '../qt5/qtbase'
Makefile:78: recipe for target 'module-qtbase-make_first' failed
make: *** [module-qtbase-make_first] Error 2


is there a workaround for this?

-- 
Best regards,
Vlad
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-22 Thread Marc Mutz 
On Thursday 22 September 2016 08:55:13 Liang Qi wrote:
> Give the merge permission to everyone is obiviously not a solution.

Not everyone, but approvers, maybe? Merges need to be reviewed like any other 
commit, so why are they special, anyway?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-22 Thread Liang Qi 
On 12 September 2016 at 11:20, Edward Welbourne 
 wrote:

> Marc Mutz said:
> > The obvious question is, then, why is only "the one person" doing merges?
> > Allow more people to upload merges, and you will get the spreading you
> desire.
>
> Several people can upload merges.
> One person looks after integration in qt5 and all its sub-modules.
> We can spread the load (indeed, I carried it for a few weeks while
> Liang was on holiday), and I believe module owners can do their own
> merges (which saves the integration team work), but the integration team
> takes responsibility for ensuring merges are happening.
> So it ends up being that Liang, as integrator, does most merges.
>

We have some/many modules are in not active mode, so the merges for them
are normally based on the release schedules. That's one of the reason to
have a merger.

A heavy load for mergers and integrators is that the new CI, COIN, doesn't
have reverse dependency check like old CI. Then if sth changed in qtbase or
qtdeclarative, the merge and integration will trigger the issue. Then very
often it's a bit difficult for us to analysis the root cause and find right
persons to fix it.

Perhaps we should set up a rule for deprecated sth, for example,
1. notify merger/integrator/others, or just add them into a list in a
wiki/web page
2. the dev of the deprecated change should do a "git grep" in all qt
project, and at least provide a fix for one of them, better to do all

For merges, the maintainers of modules should take care. At least,
qtquickcontrols2/qtwebengine are very well, it's also because developers
there are working on different features in different branches, they care
the merge themselves.

For some other modules, like qt3d/qtmultimedia/qtwayland, the help from the
maintainers and developers are also very good.

But for qtbase, it's a totally different story, too many areas, so normally
we(or I) can't say there is an active maintainer for the whole of qtbase. A
regular merge for qtbase is needed, for example, weekly. And if we can't
get response from devs very soon, who can help?

Give the merge permission to everyone is obiviously not a solution. But it
will help a lot if we have an active merger/integrator group, at least for
review.

Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development