Re: [Development] [5.7-beta] compile error with xcode-6.4

[Tim Blechmann]

>>> r.h:759:21: error: destination for this 'memmove' call is a pointer to
>>> class containing a dynamic class> 
>>>   'QPixmap'; vtable pointer will be overwritten
>>>   [-Werror,-Wdynamic-class-memaccess]>   
>>> memmove(abegin, aend, (d->size - itemsToErase -
>>> itemsUntouched) * sizeof(T)); ~~~ ^
> 
>> has support for xcode-6.4 been dropped?
> 
> Not officially. You should always use the latest XCode, no matter what, 
> though.
> 
>> https://wiki.qt.io/Qt_5.7_Tools_and_Versions still lists OSX 10.9 with
>> xcode-6.1.1
> 
> Indeed, but we're changing policies. Users are expected to use the latest and 
> greatest OS X and XCode, since they're now free for upgrading. I'm not sure 
> whether this applies to 5.7 or not.

pricing should not be the only point to consider: requiring latest xcode
versions implies requiring the latest sdk. requiring the latest sdk
means that:

* legacy code using deprecated sdk functions might not compile a certain
codebase (depending on the age of your codebase this maybe lead to
significant effort)

* compiling with a minimum osx version X of sdk version Y is different
than compiling against minimum osx version X of sdk version X. there are
subtle differences and this should not be the case if the code were
bug-free ... but we've experienced (toolchain) bugs in the past were the
only workaround was to downgrade the osx sdk, which implies downgrading
the compiler. end-users won't care if a crash is caused by a bug in
application code or in qt or in the apple toolchain. they will blame the
application.

... but we had this discussion already in the past :)

cheers,
tim


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

Re: [Development] [5.7-beta] compile error with xcode-6.4

[Jake Petroules]

On May 3, 2016, at 9:48 AM, Thiago Macieira 
> wrote:

Em terça-feira, 3 de maio de 2016, às 16:33:46 PDT, Tim Blechmann escreveu:
compiling the 5.7-beta tarball with xcode-6.4 fails with:
r.h:759:21: error: destination for this 'memmove' call is a pointer to
class containing a dynamic class>
 'QPixmap'; vtable pointer will be overwritten
 [-Werror,-Wdynamic-class-memaccess]>
   memmove(abegin, aend, (d->size - itemsToErase -
   itemsUntouched) * sizeof(T)); ~~~ ^

has support for xcode-6.4 been dropped?

Not officially. You should always use the latest XCode, no matter what, though.

Not yet but it will be at some point.

https://wiki.qt.io/Qt_5.7_Tools_and_Versions still lists OSX 10.9 with
xcode-6.1.1

Indeed, but we're changing policies. Users are expected to use the latest and
greatest OS X and XCode, since they're now free for upgrading. I'm not sure
whether this applies to 5.7 or not.

Not 5.7 yet. We haven't started ripping out any of the SDK conditions, and 
can't until https://codereview.qt-project.org/#/c/151146/ is merged, which is 
blocked by CI capability limitations at the moment.

/me pokes CI team again :)

Still, note that this is not an error. It's a warning turned to error because
of the -Werror, which means that you used -developer-build. In that case,
please send a patch. :-)

--
Thiago Macieira - thiago.macieira (AT) intel.com
 Software Architect - Intel Open Source Technology Center

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

--
Jake Petroules - 
jake.petrou...@theqtcompany.com
Consulting Services Engineer - The Qt Company
Qbs build system evangelist - qbs.io

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

Re: [Development] Qt CI reliability

[Tuukka Turunen]

> -Original Message-
> From: sean.harmer On Behalf Of Sean Harmer
> Sent: tiistaina 3. toukokuuta 2016 15.45
> To: development@qt-project.org
> Cc: Tuukka Turunen 
> Subject: Re: [Development] Qt CI reliability
> 
> 
> So in summary, I appreciate the CI is a big complex beast but it's also the
> gateway to getting contributions in and is therefore critical that it runs 
> all of
> the time, or at least as much of the time as possible. Can you investigate the
> feasibility of putting 24x7 support in place please?
> 

Yes, we can investigate this. But it may not be feasible - at least the level 
of support that can be available outside developer's office hours would most 
likely be just basic infrastructure support. 

It should be noted that we have been (and partially still are) in the process 
of being separated from the Digia group. While the CI part was mainly done 
months ago, there is overall a lot of issues ongoing that stretch the 
capabilities of IT personnel. That is of course no excuse as such, but an item 
to note anyways. 

> > we do have persons
> > dedicated to operate the CI system, as well as support from IT as
> > needed for the infrastructure. In addition, we are still putting a
> > significant effort into developing the CI further and stabilizing it.
> > And, yes, we are also continuously monitoring the infrastructure of
> > the CI systems as well as planning how to improve it further in the future.
> 
> Well, disks filling up over a weekend shows that it isn't monitored
> continuously, or rather, not acted upon. If there isn't 24x7 support then this
> is a valid outcome of course. My argument is that such support is warranted.
> 

Or at least we should make sure disks that are not automatically cleaned, are 
cleaned in advance during the office hours. I do agree with you that running 
out of a disk space should not be a reason for CI failure - and mostly it has 
not been, despite you hitting that over the weekend. 

Yours,

Tuukka

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

Re: [Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4

[Thiago Macieira]

Em terça-feira, 3 de maio de 2016, às 19:01:30 PDT, Harri Porten escreveu:
> I've seen my Qt users use -developer-build because
> 
>http://wiki.qt.io/Building_Qt_5_from_Git
> 
> proposes it and the impact not clear to everyone. Qt users naturally 
> consider themselves to be developers

I've seen people on IRC come with those errors and I've asked them to update 
the wiki page they found the instructions in to remove the -developer-build 
option. Either they've never done it or the option came back.

> The negative impact I have seen: the lack of a following "make install"
> leads to a different layout of the files on disk. Still, companies are
> sharing such builds within their team and develop their application
> against it.

That implies adding a -prefix option to configure.

> If noone minds I'll make the wording more precise.

Thanks, that would be most welcome.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] unique_ptr vs. QSharedPointer

[Thiago Macieira]

Em terça-feira, 3 de maio de 2016, às 17:00:15 PDT, Olivier Goffart escreveu:
> Because of the convention that we do not want our ABI to depends on the
> STL's  ABI.  So we can't use standard container in the signature of
> exported functions.

Which has saved our hides twice in the past few years already. Once with 
Apple's switch to libc++ and more recently with GCC/libstdc++'s breaking of 
the std::string ABI.

> The closest we have to unique_ptr in Qt is QScopedPointer.
> With the difference that QScopedPointer is not movable.
> Personally, i think we should add a move constructor to QScopedPointer, but 
> this has already been discussed there and the concensus was against it:
> http://lists.qt-project.org/pipermail/development/2013-September/012882.htm
> l Either we should reopen the discussion or create a QUniquePointer. (Or we
> should allow std types in our ABI)

The problem with using the C++11 features of the Standard Library is detecting 
what is supported. There is no monotonically-increasing version number for 
some of the implementations (read: libstdc++), so we don't know which one we 
may be compiling against. For example, GCC achieved full C++11 *language* 
support in version 4.8.1, but the Standard Library support lagged behind and 
*still* is incomplete in some areas:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html

Compare with:

https://gcc.gnu.org/onlinedocs/gcc-4.8.5/libstdc++/manual/manual/
status.html#manual.intro.status.iso

And that's not even bringing Android and QNX into the mix, which replace the 
GPLv3-licensed libstdc++ with a more permissively-licensed implementation 
(Dinkumware, Apache STLport, libc++).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

[Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4

[Harri Porten]

I got reminded of something:

On Tue, 3 May 2016, Thiago Macieira wrote:


Still, note that this is not an error. It's a warning turned to error because
of the -Werror, which means that you used -developer-build. In that case,
please send a patch. :-)


I've seen my Qt users use -developer-build because

  http://wiki.qt.io/Building_Qt_5_from_Git

proposes it and the impact not clear to everyone. Qt users naturally 
consider themselves to be developers :)


The negative impact I have seen: the lack of a following "make install" 
leads to a different layout of the files on disk. Still, companies are 
sharing such builds within their team and develop their application 
against it.


If noone minds I'll make the wording more precise.

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

Re: [Development] Header review for 5.7 (vs 5.6)

[Thiago Macieira]

Em terça-feira, 3 de maio de 2016, às 16:24:32 PDT, Edward Welbourne escreveu:
> Consequently, to take the example of qtbase, instead of looking at more
> than 100 k lines with no colouring mark-up to help you see what's really
> changed, reviewers only need to look at a little under 8 k lines, split
> up nicely by which file they're in and actually making good use of
> Gerrit's ability to display diffs nicely.  Just be sure you don't do
> anything silly like telling Gerrit to merge these commits

Thanks Eddy and everyone else who took the header diff to the next step!

BTW, I just checked and saw that the ABI report by Andrey was updated with 5.7 
beta:
http://abi-laboratory.pro/tracker/timeline/qt/

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] [5.7-beta] compile error with xcode-6.4

[Thiago Macieira]

Em terça-feira, 3 de maio de 2016, às 16:33:46 PDT, Tim Blechmann escreveu:
> compiling the 5.7-beta tarball with xcode-6.4 fails with:
> > r.h:759:21: error: destination for this 'memmove' call is a pointer to
> > class containing a dynamic class> 
> >   'QPixmap'; vtable pointer will be overwritten
> >   [-Werror,-Wdynamic-class-memaccess]>   
> > memmove(abegin, aend, (d->size - itemsToErase -
> > itemsUntouched) * sizeof(T)); ~~~ ^

> has support for xcode-6.4 been dropped?

Not officially. You should always use the latest XCode, no matter what, though.

> https://wiki.qt.io/Qt_5.7_Tools_and_Versions still lists OSX 10.9 with
> xcode-6.1.1

Indeed, but we're changing policies. Users are expected to use the latest and 
greatest OS X and XCode, since they're now free for upgrading. I'm not sure 
whether this applies to 5.7 or not.

Still, note that this is not an error. It's a warning turned to error because 
of the -Werror, which means that you used -developer-build. In that case, 
please send a patch. :-)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)?

[Adam Light]

On Mon, Mar 21, 2016 at 4:30 PM, Allan Sandfeld Jensen 
wrote:

> On Monday 21 March 2016, René J. V. Bertin wrote:
>
> > For further comparison, here's a screenshot showing
>
> >
>
> > CoreText vs Cocoa+Freetype vs XCB+Freetype+Fontconfig
>
> >
>
> > all on OS X, using a theme & style based on QtCurve.
>
> >
>
> > The XCB+Freetype rendering is hands-down the easiest on the eyes for me,
>
> > though that's of course all in the eye of the beholder. It'd be nice if
>
> > the same quality could be attained with the Cocoa QPA.
>
> >
>
> > I'd be interested in testing different ways to get the text colour right
>
> > (backported to 5.6 though ;)).
>
> >
>
> I would suggest trying to change QCocoaIntegration::styleHint
>
> and return 1.0 for QPlatformIntegration::FontSmoothingGamma instead of
> 2.0.
>
>
>

I've found that using the freetype font engine dramatically improves
performance in parts of our application that do a lot of text rendering. Is
there any way to set this style hint without actually modifying the
QCocoaIntegration source code and rebuilding Qt? We'd like to be able to
give users of our application the ability to play around with these
settings some.

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

[Development] Header review for 5.7 (vs 5.6)

[Edward Welbourne]

Hi all,

As we approach the release of 5.7.0, we naturally need to review the
changes to APIs for all the usual things.  This time, however, we
decided [0] it would be nice to actually make use of Gerrit's ability to
display changes nicely, rather than [1] displaying a diff as if it were
an enormous file to be added to a module.  While we were at it, we
decided [2] to filter out, as well as the copyright header changes our
old script discarded, various rather boring changes, such as just adding
a Q_ALWAYS_INLINE, Q_DECL_NOTHROW or Q_CONSTEXPR to a declaration.

[0] https://bugreports.qt.io/browse/QTQAINFRA-973
[1] https://codereview.qt-project.org/#/c/153346/
[2] https://codereview.qt-project.org/155745

Consequently, to take the example of qtbase, instead of looking at more
than 100 k lines with no colouring mark-up to help you see what's really
changed, reviewers only need to look at a little under 8 k lines, split
up nicely by which file they're in and actually making good use of
Gerrit's ability to display diffs nicely.  Just be sure you don't do
anything silly like telling Gerrit to merge these commits :-)

The scripts to do this are still a bit fresh (I was fixing bugs in them
on Friday and still testing yesterday) and anyone nervous of whether
they might be mistaking meaninful changes for boring is welcome to take
a look [3] (and let me know so I can fix that).  If you actually want to
run this at home, you'll need python's dulwich package installed, for
the git magic it does.

[3] https://codereview.qt-project.org/157299

Yesterday's header diffs are all listed in [4], but I'll list them here,
too, for the convenience of those whose mailers understand links:

 * https://codereview.qt-project.org/157805 – qtbase
 * https://codereview.qt-project.org/157789 – qtdeclarative
 * https://codereview.qt-project.org/157790 – qtactiveqt
 * https://codereview.qt-project.org/157791 – qtmultimedia
 * https://codereview.qt-project.org/157792 – qttools
 * https://codereview.qt-project.org/157793 – qtlocation
 * https://codereview.qt-project.org/157795 – qtconnectivity
 * https://codereview.qt-project.org/157796 – qtwayland
 * https://codereview.qt-project.org/157797 – qt3d
 * https://codereview.qt-project.org/157798 – qtquickcontrols
 * https://codereview.qt-project.org/157799 – qtserialport
 * https://codereview.qt-project.org/157800 – qtx11extras
 * https://codereview.qt-project.org/157801 – qtandroidextras
 * https://codereview.qt-project.org/157802 – qtwebsockets
 * https://codereview.qt-project.org/157803 – qtwebengine
 * https://codereview.qt-project.org/157804 – qtcanvas3d

[4] https://bugreports.qt.io/browse/QTQAINFRA-973#comment-318470

Please take a look at the modules you care about and point out anything
that's going to cause problems for the usual compatibility constraints,

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

Re: [Development] Qt CI reliability

[Jędrzej Nowacki]

On Tuesday 03 of May 2016 14:54:50 Sean Harmer wrote:
> On Monday 02 May 2016 11:14:24 Jędrzej Nowacki wrote:
> > On Saturday 30 of April 2016 20:26:20 Sean Harmer wrote:
> (...)
> What would be a *very* useful feature would be if we can trigger a test
> build of a change on a particular configuration for such cases where we
> don't have ready access to a configuration locally.
We have this feature, but it is not exposed. Qt account integration is missing 
as well as some kind of limitation to protect CI resources. If you have a 
really urgent thing to test ping me on IRC. I can run a test run for you.

> > I will ask IT about network, it seems that network interface was
> > re-configured during CI run and DHCP assigned a different IP. It should
> > not
> > happen (TM)
> 
> Yes that sort of thing should be done in a specified window out of hours
> after disabling the CI master to be able to disseminate jobs to the nodes.
Well it was not about maintenance. A node tried to re-new it's IP lease and it 
got a new IP instead of an old one. It may be some kind of DHCP miss-
configuration or operating system failed to ask in time to re-new the IP lease. 
I do not know, how on earth this could happen. I need to access logs.

> > Rule of thumb is: if logs show broken compilation it means: real problem,
> > don't blame CI. There are three main reasons, that I'm aware of, that can
> > cause the problem (sorted according to the probability):
> > 1. One of changes being integrated broke the compilation
> 
> Fine and expected and, with timely failures, not an issue.
> 
> > 2. One of module dependencies broke source compatibility
> 
> This is very rarely an issue, at least for Qt 3D.
> 
> > 3. There was a untested template update (this reason will almost disappear
> > soon)
> 
> Do you mean VM template? If so then yes that's again something that should
> ideally be verified before deployment.
Eh, wrong phrasing. Templates are tested. The problem is that the current 
process is a bit racy. Updating template is a work that require time, 
especially for testing and deployment. Regressions may appear during that time 
window. Anyway the process is about to be changed soon. 

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unique_ptr vs. QSharedPointer

[Olivier Goffart]

Am Dienstag, 3. Mai 2016, 14:19:00 CEST schrieb Shawn Rutledge:
> > On 3 May 2016, at 13:31, Marc Mutz  wrote:
> > 
> > On Tuesday 03 May 2016 13:14:05 Shawn Rutledge wrote:
> > 
> >> In what ways are they different?
> > 
> > 
> > One implements unique ownership, isn't copyable, only movable, has almost
> > zero overhead (with a stateless deleter), and is standardised from
> > C++11 on, the other implements shared ownership, is copyable and movable,
> > has the overhead of a separate control block, and is Qt-specific.
> 
> 
> OK.
> 
> But a function could return a unique_ptr, right? the caller of that function
> would thn be restricted from doing anything that results in a copy?

Yes, because unique_ptr is movable.


 
> >> Is it OK to use unique_ptr in public API starting in 5.7?
> > 
> > 
> > No.
> 
> 
> Because of the convention that we return only Qt data structures, never STL
> ones? or because we’re not sure if all compilers support unique_ptr?  Or
> something else?


Because of the convention that we do not want our ABI to depends on the STL's 
ABI.  So we can't use standard container in the signature of exported 
functions.


The closest we have to unique_ptr in Qt is QScopedPointer.
With the difference that QScopedPointer is not movable.
Personally, i think we should add a move constructor to QScopedPointer, but 
this has already been discussed there and the concensus was against it:
http://lists.qt-project.org/pipermail/development/2013-September/012882.html
Either we should reopen the discussion or create a QUniquePointer.
(Or we should allow std types in our ABI)

-- 
Olivier 

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org



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

[Development] [5.7-beta] compile error with xcode-6.4

[Tim Blechmann]

compiling the 5.7-beta tarball with xcode-6.4 fails with:

> In file included from /Users/tim/dev/qt3rd/qtbase/src/gui/image/qicon.cpp:1:
> In file included from 
> /Users/tim/dev/qt3rd/qtbase/src/gui/kernel/qt_gui_pch.h:69:
> In file included from /Users/tim/dev/qt3rd/qtbase/include/QtGui/qbitmap.h:1:
> In file included from 
> /Users/tim/dev/qt3rd/qtbase/include/QtGui/../../src/gui/image/qbitmap.h:43:
> In file included from /Users/tim/dev/qt3rd/qtbase/include/QtGui/qpixmap.h:1:
> In file included from 
> /Users/tim/dev/qt3rd/qtbase/include/QtGui/../../src/gui/image/qpixmap.h:47:
> In file included from 
> /Users/tim/dev/qt3rd/qtbase/include/QtCore/qsharedpointer.h:1:
> In file included from 
> /Users/tim/dev/qt3rd/qtbase/include/QtCore/../../src/corelib/tools/qsharedpointer.h:48:
> In file included from 
> /Users/tim/dev/qt3rd/qtbase/include/QtCore/qsharedpointer_impl.h:1:
> In file included from 
> /Users/tim/dev/qt3rd/qtbase/include/QtCore/../../src/corelib/tools/qsharedpointer_impl.h:65:
> In file included from /Users/tim/dev/qt3rd/qtbase/include/QtCore/qdebug.h:1:
> In file included from 
> /Users/tim/dev/qt3rd/qtbase/include/QtCore/../../src/corelib/io/qdebug.h:51:
> In file included from /Users/tim/dev/qt3rd/qtbase/include/QtCore/qvector.h:1:
> /Users/tim/dev/qt3rd/qtbase/include/QtCore/../../src/corelib/tools/qvector.h:759:21:
>  error: destination for this 'memmove' call is a pointer to class containing 
> a dynamic class
>   'QPixmap'; vtable pointer will be overwritten 
> [-Werror,-Wdynamic-class-memaccess]
> memmove(abegin, aend, (d->size - itemsToErase - itemsUntouched) * 
> sizeof(T));
> ~~~ ^
> /Users/tim/dev/qt3rd/qtbase/include/QtCore/../../src/corelib/tools/qvector.h:450:3:
>  note: in instantiation of member function 
> 'QVector::erase' requested
>   here
>   erase(d->begin() + i, d->begin() + i + 1); }
>   ^
> /Users/tim/dev/qt3rd/qtbase/src/gui/image/qicon.cpp:288:25: note: in 
> instantiation of member function 'QVector::remove' 
> requested here
> pixmaps.remove(idx);
> ^
> /Users/tim/dev/qt3rd/qtbase/include/QtCore/../../src/corelib/tools/qvector.h:759:21:
>  note: explicitly cast the pointer to silence this warning
> memmove(abegin, aend, (d->size - itemsToErase - itemsUntouched) * 
> sizeof(T));
> ^
> (void*)
> 1 error generated.

has support for xcode-6.4 been dropped?
https://wiki.qt.io/Qt_5.7_Tools_and_Versions still lists OSX 10.9 with
xcode-6.1.1

thanks a lot,
tim

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

Re: [Development] unique_ptr vs. QSharedPointer

[Shawn Rutledge]

> On 3 May 2016, at 13:31, Marc Mutz  wrote:
> 
> On Tuesday 03 May 2016 13:14:05 Shawn Rutledge wrote:
>> In what ways are they different?
> 
> One implements unique ownership, isn't copyable, only movable, has almost 
> zero 
> overhead (with a stateless deleter), and is standardised from C++11 on, the 
> other implements shared ownership, is copyable and movable, has the overhead 
> of a separate control block, and is Qt-specific.

OK.

But a function could return a unique_ptr, right? the caller of that function 
would then be restricted from doing anything that results in a copy?

>> Is it OK to use unique_ptr in public API starting in 5.7?
> 
> No.

Because of the convention that we return only Qt data structures, never STL 
ones? or because we’re not sure if all compilers support unique_ptr?  Or 
something else?

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

Re: [Development] Qt CI reliability

[Sean Harmer]

On Monday 02 May 2016 11:14:24 Jędrzej Nowacki wrote:
> On Saturday 30 of April 2016 20:26:20 Sean Harmer wrote:
> > Hi,
> 
> Hi,
> 
> > after yet another 5 hour wait just to be greeted with yet another random
> > failure with no build logs I'm getting really tired of the poor
> > reliability
> > of the Qt CI system.
> 
> I'm sorry about that.
> 
> > https://codereview.qt-project.org/#/c/157590/
> > 
> > has been greeted with genuine failures, failures in qtdeclarative,
> > qtxmlpatterns, multiple random failures in qt3d despite being a simple
> > change which I suspect are due to issues on one or more CI nodes.
> 
> I scanned through the failures and it seems that you had a very bad luck. I
> know CI should not be about luck and therefore I'm really sorry about that.

No need for you to apologize personally, I'm complaining about the policy to 
not have 24x7 support. I don't blame any individual and I know it's still 
improving on the technical front.

> 
> You tried to stage the change 7 times
> 1. Failed to compile qt3d (broken change
> https://codereview.qt-project.org/#/c/157593/)

Yup, such changes are part of normal development, and are expected. These are 
not an issue as long as the CI fails in a timely manner.

What would be a *very* useful feature would be if we can trigger a test build 
of a change on a particular configuration for such cases where we don't have 
ready access to a configuration locally.

> 2. Looks like a network
> connectivity failure, logs were not flushed as they should, so you can
> blame CI
> 3. Blame CI, we failed to acquire a free machine for 5h, I will look at that
> later
> 4. Failed to compile qt3d (broken change
> https://codereview.qt-project.org/#/c/157590/) 5. Failed to compile qt3d
> (broken change https://codereview.qt-project.org/#/c/157590/), same as 4 6.
> Looks like a network connectivity failure, logs were not flushed as they
> should, so you can blame CI, same as 2

Right, any time I find a link that points to nothing for the build logs I'm 
suspicious of the CI.

> 7. Passed
> 
> I will ask IT about network, it seems that network interface was
> re-configured during CI run and DHCP assigned a different IP. It should not
> happen (TM)

Yes that sort of thing should be done in a specified window out of hours after 
disabling the CI master to be able to disseminate jobs to the nodes.

> 
> Rule of thumb is: if logs show broken compilation it means: real problem,
> don't blame CI. There are three main reasons, that I'm aware of, that can
> cause the problem (sorted according to the probability):
> 1. One of changes being integrated broke the compilation

Fine and expected and, with timely failures, not an issue.

> 2. One of module dependencies broke source compatibility

This is very rarely an issue, at least for Qt 3D.

> 3. There was a untested template update (this reason will almost disappear
> soon)

Do you mean VM template? If so then yes that's again something that should 
ideally be verified before deployment.

The other factor that contributes is infrastructure: full disks, network 
outages, reconfigurations etc. These should be monitored for and acted upon and 
where possible, processes changed to avoid these situations.

> *. There was huge radiation in Finland, but that you would know from the
> news ;-)

:)

Anyway, thank you for looking into the issues here.

Cheers,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt CI reliability

[Sean Harmer]

On Monday 02 May 2016 05:05:07 Tuukka Turunen wrote:
> Hi Sean,
> 
> Firstofall, I do apologize for the inconvenience caused by the CI system. We
> are fully aware of the situation, and the effect is has for productivity.
> All the developers of The Qt Company are using exactly the same CI system.

Yes, that is a lot of people to be held up by an oft-times unreliable piece of 
infrastructure.
 
> To address the problems, we had with Jenkins based CI we started to develop
> new CI system built from the ground up to serve the needs of Qt.
> Unfortunately, it has taken us longer than we anticipated to get the new CI
> system stabile, and there are still a lot of failures caused by the CI
> itself. We are also continuously improving the test asset to make it less
> prone for errors, including identification of flaky cases and fixing and/or
> temporarily blacklisting these. 

The flaky test related failure rate has indeed improved a great deal over the 
last 12 months. Thanks to all who have helped with this. The problems we're 
suffering now seem to be more related to infrastructure issues as Jędrek has 
pointed out.

I think part of the problem is also perception. From outside of TQC, 
contributors have no visibility of the status of an integration beyond the 
gerrit "INTEGRATING" status. This turns it into a black box that can take most 
of a working day to result in a frustating failure.

Would it be possible for you to expose the view of the currently running 
integrations and their status on each node/configuration so that we can see if 
something looks like it might be broken and can approach a sysadmin?
 
> While we unfortunately do not have 24x7 sysadmins,

And this is a problem imho. The CI is a critical system that needs to be 
running 24x7 to support people in different timezones and during out of hours 
work in Europe. If I'm busy with paying project work during office hours, then 
I 
try to do what I can on Qt 3D out of normal hours but several times I've had 
to waste hours at weekends and evenings trying to shepherd changes through. 
This in turn then just adds to the load on the CI system during office hours 
when the system is able to integrate once again.

So in summary, I appreciate the CI is a big complex beast but it's also the 
gateway to getting contributions in and is therefore critical that it runs all 
of the time, or at least as much of the time as possible. Can you investigate 
the feasibility of putting 24x7 support in place please?

> we do have persons
> dedicated to operate the CI system, as well as support from IT as needed
> for the infrastructure. In addition, we are still putting a significant
> effort into developing the CI further and stabilizing it. And, yes, we are
> also continuously monitoring the infrastructure of the CI systems as well
> as planning how to improve it further in the future.

Well, disks filling up over a weekend shows that it isn't monitored 
continuously, or rather, not acted upon. If there isn't 24x7 support then this 
is a valid outcome of course. My argument is that such support is warranted.

Kind regards,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt API consistency (was: Re: unique_ptr vs. QSharedPointer)

[Andre Poenitz]

I'd like another question be answered before the discussion on yet 
another unsystematic use of yet another language or library feature 
starts:

How important is API consistency for Qt today?

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

Re: [Development] unique_ptr vs. QSharedPointer

[Marc Mutz]

On Tuesday 03 May 2016 13:14:05 Shawn Rutledge wrote:
> In what ways are they different?

One implements unique ownership, isn't copyable, only movable, has almost zero 
overhead (with a stateless deleter), and is standardised from C++11 on, the 
other implements shared ownership, is copyable and movable, has the overhead 
of a separate control block, and is Qt-specific.

> Is it OK to use unique_ptr in public API starting in 5.7?

No.

> How about in internal implementation?

We have no experience, except in platform-specific code.

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] unique_ptr vs. QSharedPointer

[Philippe]

These are completely different.

Maybe you mean 

shared_ptr vs. QSharedPointer ?

Philippe

On Tue, 3 May 2016 11:14:05 +
Shawn Rutledge  wrote:

> In what ways are they different?  
> 
> Is it OK to use unique_ptr in public API starting in 5.7?
> 
> How about in internal implementation?
> 
> ___
> 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] unique_ptr vs. QSharedPointer

[Shawn Rutledge]

In what ways are they different?  

Is it OK to use unique_ptr in public API starting in 5.7?

How about in internal implementation?

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

[Development] User script for Qt's gerrit to have code.woboq.org integration

[Olivier Goffart]

Hi,

Some time ago, I made an user script that tries to integrate with https://
code.woboq.org/qt5 with gerrit.  (i posted it once but it was in a deep thread 
so you might not have noticed it)

With that script, you can just click on a function in the code on gerrit and 
it will lookup in the code.woboq.org database and show the signature in a 
tooltip and links to code.woboq.org. (screenshot: 
http://i.imgur.com/Q3a2ixz.png ). It shows a disambiguation popup if there 
are several possibilities.
It also makes the filename in the header of the diff clickable to the 
corresponding file on code.woboq.org

The user script is there: 
   https://code.woboq.org/qt-gerrit.user.js
You can use it with the Greasmonkey extension on Firefox or the Tampermonkey 
extension on Chrome, or whatever equivalent extension for your browser.


Feedback welcome.

-- 
Olivier 

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org

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

Re: [Development] Retiring libtiff too

[Shawn Rutledge]

> On 3 May 2016, at 08:39, Lars Knoll  wrote:
> Ideally, I would like to get rid of these libraries in src/3rdparty. Instead, 
> we should build up to date versions of these libs in Coin, and simply ship 
> those together with our Qt libraries. With the online installers it should in 
> the longer term even be possible to ship updates for these libraries 
> independent of a new Qt release.

Sounds good to keep them up-to-date.  But if a library makes a 
source-incompatible change or introduces a bug, it could cause some scrambling 
on our end to catch up with API changes, or falling back to the last-known-good 
version.  So, use their HEADs most of the time but also have the ability to 
freeze for short periods at a specific SHA1? or use actual tagged releases most 
of the time but also have some way of falling back?

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

Re: [Development] Retiring libtiff too

[Shawn Rutledge]

> On 3 May 2016, at 08:39, Lars Knoll  wrote:
> Ideally, I would like to get rid of these libraries in src/3rdparty. Instead, 
> we should build up to date versions of these libs in Coin, and simply ship 
> those together with our Qt libraries. With the online installers it should in 
> the longer term even be possible to ship updates for these libraries 
> independent of a new Qt release.

Sounds good to keep them up-to-date.  But if a library makes a 
source-incompatible change or introduces a bug, it could cause some scrambling 
on our end to catch up with API changes, or falling back to the last-known-good 
version.  So, use their HEADs most of the time but also have the ability to 
freeze for short periods at a specific SHA1? or use actual tagged releases most 
of the time but also have some way of falling back?

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

Re: [Development] Retiring libtiff too

[Thiago Macieira]

Em terça-feira, 3 de maio de 2016, às 07:06:41 PDT, Lars Knoll escreveu:
> On 03/05/16 08:58, "Development on behalf of Thiago Macieira"
>  thiago.macie...@intel.com> wrote:
 
> 
> >Em terça-feira, 3 de maio de 2016, às 06:39:42 PDT, Lars Knoll escreveu:
> >
> >> Ideally, I would like to get rid of these libraries in src/3rdparty.
> >> Instead, we should build up to date versions of these libs in Coin, and
> >> simply ship those together with our Qt libraries. With the online
> >> installers it should in the longer term even be possible to ship updates
> >> for these libraries independent of a new Qt release.
> >
> >
> >How about Windows users who build from source?
> 
> I don't see an issue here. If we have them in Coin, we should get both
> source and binary packages.

I meant that those users are used to the Qt build (especially qtbase) 
including just about everything they need for a complete Qt. It's not what I 
advise, but it's a convenience those users will miss. So I am asking: are we 
ok with dropping that convenience?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Retiring libtiff too

[Lars Knoll]

On 03/05/16 08:58, "Development on behalf of Thiago Macieira" 
 wrote:

>Em terça-feira, 3 de maio de 2016, às 06:39:42 PDT, Lars Knoll escreveu:
>> Ideally, I would like to get rid of these libraries in src/3rdparty.
>> Instead, we should build up to date versions of these libs in Coin, and
>> simply ship those together with our Qt libraries. With the online
>> installers it should in the longer term even be possible to ship updates
>> for these libraries independent of a new Qt release.
>
>How about Windows users who build from source?

I don't see an issue here. If we have them in Coin, we should get both source 
and binary packages.

Cheers,
Lars

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

Re: [Development] Retiring libtiff too

[Thiago Macieira]

Em terça-feira, 3 de maio de 2016, às 06:39:42 PDT, Lars Knoll escreveu:
> Ideally, I would like to get rid of these libraries in src/3rdparty.
> Instead, we should build up to date versions of these libs in Coin, and
> simply ship those together with our Qt libraries. With the online
> installers it should in the longer term even be possible to ship updates
> for these libraries independent of a new Qt release.

How about Windows users who build from source?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] Retiring libtiff too

[Lars Knoll]

On 02/05/16 20:20, "Development on behalf of Thiago Macieira" 
 wrote:

>On segunda-feira, 2 de maio de 2016 18:07:29 PDT Lars Knoll wrote:
>> >> So while I don't like us having copies of these libraries in our
>> >> repositories, not shipping any support for these image formats in our
>> >> packages is not a good option neither.
>> >
>> >I kinda disagree. I would prefer an opt-in for those poeple.
>> 
>> That's of course an option, but if the opt-in means 'download libtiff
>> yourself, figure out how to compile it, then recompile qtimageformats', we
>> have a very user-unfriendly way of solving the problem.
>
>> >Aside from not including it. How are the qtimageformats packaged in our
>> >binaries? Are they installed automatically?
>> 
>> Currently they are automatically installed.
>
>At the very least we should not automatically install it. We can provide the 
>binaries for opt-in installation for those who want/need it, with the 
>appropriate warning that they need to follow the security bulletins.
>
>In fact, we should have an installer page showing all the bundled third-party 
>libraries and let people know that they're there for convenience only and it's 
>their responsibility to follow security bulletins for those pieces of 
>software. We will upgrade only on our own releases and we will not provide 
>security updates in-between.
>
>But we should provide security updates on EVERY release. That means we need to 
>follow the CVEs for every piece of bundled third-party software, be it source 
>or binary form, and apply patches that may be necessary.

Agree with this.

Ideally, I would like to get rid of these libraries in src/3rdparty. Instead, 
we should build up to date versions of these libs in Coin, and simply ship 
those together with our Qt libraries. With the online installers it should in 
the longer term even be possible to ship updates for these libraries 
independent of a new Qt release.

Cheers,
Lars

>
>In time, the following CVEs are outstanding for libtiff as of version 4.0.6.
>
>CVE-2014-9655 CVE-2015-1547 CVE-2015-8665 CVE-2015-8683
>CVE-2015-7554 CVE-2015-8668
>
>-- 
>Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>
>___
>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