[Development] HEADS-UP: Branching from '5.9' to '5.9.0' completed

[Jani Heikkinen]

> -Original Message-
> From: Jani Heikkinen
> Sent: torstaina 27. huhtikuuta 2017 14.00
> To: development@qt-project.org; releas...@qt-project.org
> Subject: HEADS-UP: Branching from '5.9' to '5.9.0' started
> 
> Hi,
> We have soft branched '5.9.0' from '5.9'. Please start using '5.9.0' for new
> changes targeted to Qt 5.9.0 release. There should be enough time to finalize
> ongoing changes in '5.9'; final downmerge will happen Thursday 4th May.
> 
> br,
> Jani
> 

Final downmerges are now done(*) and branching is completed. '5.9' is for Qt 
5.9.1 from now on and all changes targeted to Qt 5.9.0 release must be done in 
'5.9.0'

br,
Jani

(*) Webengine were delayed yesterday due to ongoing integrations but most 
probably finalized now as well
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Coin: using 64-bit Windows host for 32-bit builds

[Konstantin Tokarev]

05.05.2017, 01:11, "Thiago Macieira" :
> Em quinta-feira, 4 de maio de 2017, às 14:22:55 PDT, Konstantin Tokarev
> escreveu:
>>  Unfortunately, VS is the worst offender at the moment, it does not have
>>  anything like -g1, or like -g0 (i.e. option to negate previously added /Zi)
>
> IIRC, the 32-bit linker is a 32-bit application too if you use "vcvarsall
> x86".
>
> You need a cross-compilation setup, like "vcvarsall x64_x86".

Yes, use 64-bit tools while compiling for 32-bit target. That requires 64-bit OS
image to start with.

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

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

Re: [Development] Coin: using 64-bit Windows host for 32-bit builds

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 14:22:55 PDT, Konstantin Tokarev 
escreveu:
> Unfortunately, VS is the worst offender at the moment, it does not have
> anything like -g1, or like -g0 (i.e. option to negate previously added /Zi)

IIRC, the 32-bit linker is a 32-bit application too if you use "vcvarsall 
x86".

You need a cross-compilation setup, like "vcvarsall x64_x86".

-- 
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] Coin: using 64-bit Windows host for 32-bit builds

[Konstantin Tokarev]

05.05.2017, 00:01, "Kevin Kofler" :
> Konstantin Tokarev wrote:
>>  It is needed because large projects, namely QtWebEngine and QtWebKit
>>  (wip/next branch) are too large for making 32-bit debug builds on 32-bit
>>  OS. In case of QtWebKit it's possbile to work around this problem by
>>  issuing debug info for API implementation only, however this reduces
>>  debuggability.
>
> In Fedora, we use this to build at least SOME debugging information (-g1
> level rather than the default -g which exhausts the address space) for
> QtWebEngine on 32-bit architectures:
> http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qt5-qtwebengine.spec#n374
> http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qt5-qtwebengine.spec#n395
>
> (Also note that we build with
> CONFIG+="webcore_debug v8base_debug force_debug_info"
> or we would not be getting complete debugging information anywhere.)
>
> The -g1 trick is probably also workable for QtWebKit if it is hitting the
> same issue on any GCC target (including MinGW). But I don't know whether
> Visual C++ has anything comparable.

Unfortunately, VS is the worst offender at the moment, it does not have 
anything like -g1,
or like -g0 (i.e. option to negate previously added /Zi)

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

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

Re: [Development] Coin: using 64-bit Windows host for 32-bit builds

[Kevin Kofler]

Konstantin Tokarev wrote:
> It is needed because large projects, namely QtWebEngine and QtWebKit
> (wip/next branch) are too large for making 32-bit debug builds on 32-bit
> OS. In case of QtWebKit it's possbile to work around this problem by
> issuing debug info for API implementation only, however this reduces
> debuggability.

In Fedora, we use this to build at least SOME debugging information (-g1
level rather than the default -g which exhausts the address space) for
QtWebEngine on 32-bit architectures:
http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qt5-qtwebengine.spec#n374
http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qt5-qtwebengine.spec#n395

(Also note that we build with
CONFIG+="webcore_debug v8base_debug force_debug_info"
or we would not be getting complete debugging information anywhere.)

The -g1 trick is probably also workable for QtWebKit if it is hitting the
same issue on any GCC target (including MinGW). But I don't know whether
Visual C++ has anything comparable.

Kevin Kofler

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

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 11:33:44 PDT, René J. V. Bertin 
escreveu:
> Thiago Macieira wrote:
> > How could it be? The problem happens with a host application that is a
> > code
> > generator that doesn't connect to the bus.
> 
> Indeed. Does it even need to link to QtDbus then?

It links to QtBootstrapDBus.

-- 
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] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

04.05.2017, 19:35, "Oswald Buddenhagen" :
> On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
>>  03.05.2017, 17:27, "Sergio Martins" :
>>  > On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>  >>  Remaining question is versioning. While it's fine to dub current
>>  >>  release "5.9" (but not 5.0, because we will have another WebKit update
>>  >>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>  >>
>>  >>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
>>  >>  or is updated
>>  >>  2. It makes people believe that QtWebKit 5.N should be used with Qt
>>  >>  5.N only. QtWebKit supports wide range of Qt versions (starting from
>>  >>  5.2 as of now), and can be used e.g. as security update in Linux
>>  >>  distro that does not normally update Qt version during its life cycle.
>>  >>
>>  >>  Any comments?
>>  >
>>  > If Qt and QtWebKit will have different release schedules then that
>>  > numbering would indeed confuse people.
>>
>>  What about choice of new versioning scheme?
>>
>>  I'm leaning towards "6.0.0" number, because it's larger than any 5.x and 
>> makes it
>>  clear that versioning is different now. Bug fixes will increment patch 
>> version (6.0.x),
>>  WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major
>>  verison (7.0 etc.)
>>
>>  Qt5 supermodule will be tracking latest available stable branch. When 
>> release branch
>>  is created (e.g. 5.10.0), corresponding patch release branch is created in 
>> qtwebkit
>>  repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release 
>> branches.
>>
>>  However, I'm not sure about two things:
>>  1) Is it possible to have custom branch names in qtwebkit repository, or 
>> there need to
>>  be virtual 5.10 etc. branches to match other modules?
>>  2) What about bug tracking in JIRA? I would like to keep existing issues as 
>> is, but assing
>>  new release numbers to items fixed in new releases
>
> i'll say outright that you can't be part of the qt supermodule and yet
> have independent releases. while that was the plan once upon a time, the
> whole release infrastructure simply doesn't deliver, and even just
> diverging branch names are a pita (proved by enginio). as a product, qt
> is as monolithic as ever.

Understood: no custom branch/tag names in official repo.

>
> your release cycle concerns seem to be centered around the webkit
> backend, and you can deal with that by lowering the compatibility
> guarantees of patch releases at this level, i.e. take the freedom to
> upgrade webkit in a patch release. as long as you keep qt's api/abi
> compat promises, you're fine. that means that you will not be able to
> expose new webkit features until the next minor release if they require
> new api.

That's probably fine with me, except 2 moments that seem to require "out of 
band" releases:

1. Something should be done with current release. As I said, it's not an option 
to postpone
it to 5.10, however it also cannot be released as 5.9.1 because there are API 
additions
which I don't want to revert (in particular because these APIs were already 
shipped by
Linux distros that chose to provide TP4 and TP5). Also there is a change in 
QDataStream
format of QWebHistory.

2. Security updates. WebKitGTK team provides several patch releases for each 
stable branch,
which contain only fixes for bugs and security issues, and towards the end of 
release life cycle
they became primarily security updates. I think we should be able to release 
such updates ASAP,
by making up some tag name and scheduling custom build against newest patch 
release of Qt.

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

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

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

[René J . V . Bertin]

Thiago Macieira wrote:

> How could it be? The problem happens with a host application that is a code
> generator that doesn't connect to the bus.

Indeed. Does it even need to link to QtDbus then?

R.

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

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 11:06:54 PDT, René J. V. Bertin 
escreveu:
> Thiago Macieira wrote:
> > I think our ARM builds are little-endian, so endianness cannot be an
> > issue.
> > 
> > The problem happens before any ARM code is run, so it's not an emulation
> > or
> > processor issue. It must be a cross-compilation (bootstrapping) issue.
> 
> So it cannot be something that has to do with a host application connecting
> to a dbus daemon running off ARM code? A communications glitch would be the
> simplest reason for a timeout in IPC context, in this case presumably when
> disconnecting from a DBus daemon.

How could it be? The problem happens with a host application that is a code 
generator that doesn't connect to the bus.

> Something else: a standard llvm/clang install will generate code for ARM on
> demand without need to install a dedicated cross-compiler. Maybe worth
> checking if the same issue arises with clang (on a CI system or a developer
> workstation)?

For someone else.

As I said, I don't cross-compile.

-- 
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] DBus signals for (dlclose'd) style plugin causing crash during application exit?

[Konstantin Tokarev]

04.05.2017, 21:07, "René J. V. Bertin" :
> Thiago Macieira wrote:
>
>>  I think our ARM builds are little-endian, so endianness cannot be an issue.
>>
>>  The problem happens before any ARM code is run, so it's not an emulation or
>>  processor issue. It must be a cross-compilation (bootstrapping) issue.
>
> So it cannot be something that has to do with a host application connecting 
> to a
> dbus daemon running off ARM code? A communications glitch would be the 
> simplest
> reason for a timeout in IPC context, in this case presumably when 
> disconnecting
> from a DBus daemon.
>
> Something else: a standard llvm/clang install will generate code for ARM on
> demand without need to install a dedicated cross-compiler.

...except that you need target-specific binutils, glibc, kernel headers...

> Maybe worth checking
> if the same issue arises with clang (on a CI system or a developer 
> workstation)?
>
> R
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

[René J . V . Bertin]

Thiago Macieira wrote:


> I think our ARM builds are little-endian, so endianness cannot be an issue.
> 
> The problem happens before any ARM code is run, so it's not an emulation or
> processor issue. It must be a cross-compilation (bootstrapping) issue.

So it cannot be something that has to do with a host application connecting to 
a 
dbus daemon running off ARM code? A communications glitch would be the simplest 
reason for a timeout in IPC context, in this case presumably when disconnecting 
from a DBus daemon.

Something else: a standard llvm/clang install will generate code for ARM on 
demand without need to install a dedicated cross-compiler. Maybe worth checking 
if the same issue arises with clang (on a CI system or a developer workstation)?

R

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

Re: [Development] QtWebKit is coming back (part 2)

[Oswald Buddenhagen]

On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
> 03.05.2017, 17:27, "Sergio Martins" :
> > On 2017-05-03 15:02, Konstantin Tokarev wrote:
> >>  Remaining question is versioning. While it's fine to dub current
> >>  release "5.9" (but not 5.0, because we will have another WebKit update
> >>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
> >>
> >>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
> >>  or is updated
> >>  2. It makes people believe that QtWebKit 5.N should be used with Qt
> >>  5.N only. QtWebKit supports wide range of Qt versions (starting from
> >>  5.2 as of now), and can be used e.g. as security update in Linux
> >>  distro that does not normally update Qt version during its life cycle.
> >>
> >>  Any comments?
> >
> > If Qt and QtWebKit will have different release schedules then that
> > numbering would indeed confuse people.
> 
> What about choice of new versioning scheme?
> 
> I'm leaning towards "6.0.0" number, because it's larger than any 5.x and 
> makes it
> clear that versioning is different now. Bug fixes will increment patch 
> version (6.0.x),
> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major
> verison (7.0 etc.)
> 
> Qt5 supermodule will be tracking latest available stable branch. When release 
> branch
> is created (e.g. 5.10.0), corresponding patch release branch is created in 
> qtwebkit
> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release 
> branches.
> 
> However, I'm not sure about two things:
> 1) Is it possible to have custom branch names in qtwebkit repository, or 
> there need to
> be virtual 5.10 etc. branches to match other modules?
> 2) What about bug tracking in JIRA? I would like to keep existing issues as 
> is, but assing
> new release numbers to items fixed in new releases
> 
i'll say outright that you can't be part of the qt supermodule and yet
have independent releases. while that was the plan once upon a time, the
whole release infrastructure simply doesn't deliver, and even just
diverging branch names are a pita (proved by enginio). as a product, qt
is as monolithic as ever.

your release cycle concerns seem to be centered around the webkit
backend, and you can deal with that by lowering the compatibility
guarantees of patch releases at this level, i.e. take the freedom to
upgrade webkit in a patch release. as long as you keep qt's api/abi
compat promises, you're fine. that means that you will not be able to
expose new webkit features until the next minor release if they require
new api.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] DBus signals for (dlclose'd) style plugin causing crash during application exit?

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 08:03:47 PDT, René J. V. Bertin 
escreveu:
> Here's another shot in the dark: that's a 64bit Intel host running an ARM
> cross build, maybe even for 32bit. I don't really know how you run tests on
> there (emulation?) but couldn't this be something that has to do with
> endianness and/or 32/64 bit differences? And couldn't it be something that
> has long been latent but was never triggered in a way that it caused
> problems?

I think our ARM builds are little-endian, so endianness cannot be an issue.

The problem happens before any ARM code is run, so it's not an emulation or 
processor issue. It must be a cross-compilation (bootstrapping) issue.

-- 
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] Coin: using 64-bit Windows host for 32-bit builds

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 07:52:24 PDT, Konstantin Tokarev 
escreveu:
> It is needed because large projects, namely QtWebEngine and QtWebKit
> (wip/next branch) are too large for making 32-bit debug builds on 32-bit OS.
> In case of QtWebKit it's possbile to work around this problem by issuing
> debug info for API implementation only, however this reduces debuggability.

Way back in Qt 4 times, QtWebKit was never built in debug mode even for debug 
Qt builds. The library was just too big. I think we should adopt the same 
policy. The number of people who may want to debug into the WebKit proper code 
is small.

-- 
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] DBus signals for (dlclose'd) style plugin causing crash during application exit?

[René J . V . Bertin]

Thiago Macieira wrote:

> I could start firing in the dark. For example, one characteristic of the above
> build that never matches any of my local tests is that it's a cross-
> compilation to ARM. So we could disable QtDBus by default when cross-
> compiling.

I noticed that, and wondered if the issue affects only ARM (cross) builds.

Here's another shot in the dark: that's a 64bit Intel host running an ARM cross 
build, maybe even for 32bit. I don't really know how you run tests on there 
(emulation?) but couldn't this be something that has to do with endianness 
and/or 32/64 bit differences? And couldn't it be something that has long been 
latent but was never triggered in a way that it caused problems?

R.

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

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Sergio Martins]

On 2017-05-04 15:18, Thiago Macieira wrote:

Em quinta-feira, 4 de maio de 2017, às 06:58:53 PDT, Konstantin Tokarev
escreveu:

But we could have Linux clang configuration with clazy plugin.


Why? Clazy is not part of our development philosophy. We should only do 
that
after there's a QUIP explaining which options in Clazy we use (which 
there

isn't).


Probably the QUIP shouldn't be about clazy /per se/, but about which 
coding practices we want to enforce via static analysis tooling.
clazy's current warning set could be used as a starting base for the 
discussion though, because it exists.



But more about that *later*! There's interesting things in the pipeline 
which KDAB would like to show first.




Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Coin: using 64-bit Windows host for 32-bit builds

[Konstantin Tokarev]

Hello,

I was told that there is some ongoing work to make subject possible.
What is the current status?

It is needed because large projects, namely QtWebEngine and QtWebKit
(wip/next branch) are too large for making 32-bit debug builds on 32-bit OS.
In case of QtWebKit it's possbile to work around this problem by issuing
debug info for API implementation only, however this reduces debuggability.

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

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 07:34:34 PDT, Sergio Martins escreveu:
> On 2017-05-04 14:53, Thiago Macieira wrote:
> > Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet
> > 
> > escreveu:
> >> Clang 4: Do we really need this to be tested with Linux in CI? If yes,
> >> then
> >> which configuration it will be replaced?
> > 
> > I don't think we need to. The macOS builds should be sufficient for
> > almost
> > everything intrinsic to Clang. Those of us who test it on Linux will
> > submit
> > fixes as needed.
> 
> We've introduced bugs in the past that would have been caught
> immediately by clang + Werror if it had been in the CI.
> clang has warnings that gcc doesn't have. Apple Clang is based on older
> clang (which one?), so doesn't have all the nice warnings.

I'm not doubting it has benefits. That's why I build with it on my machine. In 
fact, I build linux-clang more often than macx-clang or win32-msvc.

But Heikki's message implies it's not in the CI, so we're not losing anything 
we had. We're just not adding something we've never had.

> I don't know the cost of adding it to the CI, so I won't comment on the
> cost/benefit relation.

That's exactly the point. The question was: "what should it replace" and I 
don't think we can confidently say it should replace anything.

-- 
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] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Sergio Martins]

On 2017-05-04 14:53, Thiago Macieira wrote:
Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet 
escreveu:
Clang 4: Do we really need this to be tested with Linux in CI? If yes, 
then

which configuration it will be replaced?


I don't think we need to. The macOS builds should be sufficient for 
almost
everything intrinsic to Clang. Those of us who test it on Linux will 
submit

fixes as needed.


We've introduced bugs in the past that would have been caught 
immediately by clang + Werror if it had been in the CI.
clang has warnings that gcc doesn't have. Apple Clang is based on older 
clang (which one?), so doesn't have all the nice warnings.



I don't know the cost of adding it to the CI, so I won't comment on the 
cost/benefit relation.




Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 07:21:03 PDT, Konstantin Tokarev 
escreveu:
> Yes. But using 5.$large_number seems wrong too, because there is no hard
> upper limit for Qt 5.x series

No, but it's highly unlikely we'll get to 5.20 or 5.100.

-- 
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] QtWebKit is coming back (part 2)

[Sergio Martins]

On 2017-05-04 14:51, Konstantin Tokarev wrote:

03.05.2017, 17:27, "Sergio Martins" :

On 2017-05-03 15:02, Konstantin Tokarev wrote:

 Remaining question is versioning. While it's fine to dub current
 release "5.9" (but not 5.0, because we will have another WebKit 
update

 in 5.10 time frame), using Qt versions in QtWebKit has downsides:

 1. It is not clear if 5.N+1 ships with the same WebKit branch as 
5.N,

 or is updated
 2. It makes people believe that QtWebKit 5.N should be used with Qt
 5.N only. QtWebKit supports wide range of Qt versions (starting from
 5.2 as of now), and can be used e.g. as security update in Linux
 distro that does not normally update Qt version during its life 
cycle.


 Any comments?


If Qt and QtWebKit will have different release schedules then that
numbering would indeed confuse people.


What about choice of new versioning scheme?

I'm leaning towards "6.0.0" number, because it's larger than any 5.x
and makes it
clear that versioning is different now. Bug fixes will increment patch
version (6.0.x),
WebKit updates minor version (6.1.x etc), API/ABI breaking changes - 
major

verison (7.0 etc.)


If you go down that route just make sure 7.0 is out before Qt 6 is 
released, otherwise it's confusing too.


No idea about your other questions.



Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

04.05.2017, 17:17, "Thiago Macieira" :
> Em quinta-feira, 4 de maio de 2017, às 06:51:45 PDT, Konstantin Tokarev
> escreveu:
>>  I'm leaning towards "6.0.0" number, because it's larger than any 5.x and
>>  makes it clear that versioning is different now. Bug fixes will increment
>>  patch version (6.0.x), WebKit updates minor version (6.1.x etc), API/ABI
>>  breaking changes - major verison (7.0 etc.)
>
> I thought you weren't breaking either source or binary compatibility.

Correct.

> So using a new major number sounds wrong.

Yes. But using 5.$large_number seems wrong too, because there is no hard
upper limit for Qt 5.x series

>
> And what would you do when Qt 6 gets released in a couple of years?

There will be QtWebKit 7.x by then, because there are some desirable changes
that would break ABI. There is no clear plan yet, though.

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

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

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 06:58:53 PDT, Konstantin Tokarev 
escreveu:
> But we could have Linux clang configuration with clazy plugin.

Why? Clazy is not part of our development philosophy. We should only do that 
after there's a QUIP explaining which options in Clazy we use (which there 
isn't).

-- 
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] QtWebKit is coming back (part 2)

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 06:51:45 PDT, Konstantin Tokarev 
escreveu:
> I'm leaning towards "6.0.0" number, because it's larger than any 5.x and
> makes it clear that versioning is different now. Bug fixes will increment
> patch version (6.0.x), WebKit updates minor version (6.1.x etc), API/ABI
> breaking changes - major verison (7.0 etc.)

I thought you weren't breaking either source or binary compatibility. So using 
a new major number sounds wrong.

And what would you do when Qt 6 gets released in a couple of years?

-- 
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] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Konstantin Tokarev]

04.05.2017, 16:53, "Thiago Macieira" :
> Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet escreveu:
>>  Clang 4: Do we really need this to be tested with Linux in CI? If yes, then
>>  which configuration it will be replaced?
>
> I don't think we need to. The macOS builds should be sufficient for almost
> everything intrinsic to Clang. Those of us who test it on Linux will submit
> fixes as needed.

But we could have Linux clang configuration with clazy plugin.

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

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

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

04.05.2017, 16:52, "Thiago Macieira" :
> Em quinta-feira, 4 de maio de 2017, às 00:17:30 PDT, Jani Heikkinen escreveu:
>>  > I hope for this (if possible, in 5.9 with Technology preview status
>>
>>  I don't think adding new TP in 5.9 at this point isn't that wise anymore. We
>>  have agreed to get all these new submodules (also TP ones) in before FF and
>>  so on 5.10 is first option.
>
> Fair enough, but QtWebKit can release a TP a little afterwards and just say
> it's compatible with Qt 5.9.

Will it be possbile to get binary packages into repositories of online SDK 
updater?

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

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

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet escreveu:
> Clang 4: Do we really need this to be tested with Linux in CI? If yes, then
> which configuration it will be replaced?

I don't think we need to. The macOS builds should be sufficient for almost 
everything intrinsic to Clang. Those of us who test it on Linux will submit 
fixes as needed.

-- 
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] QtWebKit is coming back (part 2)

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 00:17:30 PDT, Jani Heikkinen escreveu:
> > I hope for this (if possible, in 5.9 with Technology preview status 
> 
> I don't think adding new TP in 5.9 at this point isn't that wise anymore. We
> have agreed to get all these new submodules (also TP ones) in before FF and
> so on 5.10 is first option.

Fair enough, but QtWebKit can release a TP a little afterwards and just say 
it's compatible with Qt 5.9.

-- 
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] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

03.05.2017, 17:27, "Sergio Martins" :
> On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>  Remaining question is versioning. While it's fine to dub current
>>  release "5.9" (but not 5.0, because we will have another WebKit update
>>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>
>>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
>>  or is updated
>>  2. It makes people believe that QtWebKit 5.N should be used with Qt
>>  5.N only. QtWebKit supports wide range of Qt versions (starting from
>>  5.2 as of now), and can be used e.g. as security update in Linux
>>  distro that does not normally update Qt version during its life cycle.
>>
>>  Any comments?
>
> If Qt and QtWebKit will have different release schedules then that
> numbering would indeed confuse people.

What about choice of new versioning scheme?

I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes 
it
clear that versioning is different now. Bug fixes will increment patch version 
(6.0.x),
WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major
verison (7.0 etc.)

Qt5 supermodule will be tracking latest available stable branch. When release 
branch
is created (e.g. 5.10.0), corresponding patch release branch is created in 
qtwebkit
repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release 
branches.

However, I'm not sure about two things:
1) Is it possible to have custom branch names in qtwebkit repository, or there 
need to
be virtual 5.10 etc. branches to match other modules?
2) What about bug tracking in JIRA? I would like to keep existing issues as is, 
but assing
new release numbers to items fixed in new releases



Rationale why using Qt version is not optimal anymore:

1. New QtWebKit is using stable branch of WebKitGTK to simplify maintenance, and
plan is to continue doing this in future. Currenly WebKitGTK creates new stable 
branch
twice a year and follows GNOME release schedule. While this more or less matches
Qt release schedule, there may be unfortunate cases when schedules mismatch, and
WebKit upgrade won't be possible in time. Keeping WebKit not upgraded increases
maintenance burden, because it's harder to cherry-pick patches from diverging 
trunk,
and it's not possible anymore to reuse backporting work of WebKitGTK team.

In case WebKit upgrade is finished before Qt release, it's highly desirable to 
allow
downstreams (e.g. Linux distros) to get newer version faster.

In case WebKit upgrade was skipped for some reason when new Qt release is
made, it's important to reflect this in version number as well

2. There may be schedule missses because of lacking man power in QtWebKit team.
Like now for example, release is long overdue and it's just unacceptable to 
hold it
for more than half of year again.

3. As I already mentioned in the starting message, surprisingly large number of 
people
believe that QtWebKit x.y is tied to Qt x.y, while it supports a range of Qt 
versions,
and can be used as security update in Linux distros that do not normally update 
Qt
version during their release life cycle.

Historically, QtWebKit always supported at least N-1 release of Qt, and 
versioning
scheme used in Qt 4 times since Qt 4.7 (QtWebKit 2.0 - 2.3) better reflected 
this fact.


>
> Have you thought about an LTS version too ? What would LTS mean, for
> QtWebKit ? I think during the LTS lifetime we would still need to update
> the inner WebKit, for security reasons, (that even happened for
> QtWebEngine in a 5.6.x patch release).
>
> Thanks for your efforts on this!
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed

[Alexandru Croitor]

Hi,

I'm actually looking into this at the moment, as per the created issue here 
QTBUG-60443

I haven't completely finished my investigation, which I will post to the bug 
report.

But the gist of it is:
- the WebEngine / Chromium sub process calls manually sandbox_init, which is 
the macOS private API for enabling the sandbox. That interferes
with the sandbox which you enable via codesign entitlements, which gives the 
"sandbox reinit denied' issue, and crashed process.

- if the above call is commented out, then you need to make sure that the Qt 
Application is signed with sandbox setup entitlements, and the WebEngineProcess 
is signed with sandbox "inherit" entitlements, otherwise I couldn't get it to  
work.

- Both of those entitlements have to specify a valid Team ID + prefix in the 
entitlment com.apple.security.application-groups
key.

- Google Chrome itself does not enable sandboxing via codesign entitlements, 
but only enables it for subprocess via sandbox_init, leaving the main process 
without a sandbox.

Thus my preliminary suggestion is not to enable codesign sandboxing for 
QtWebengine applications.

I'm open to discussion on this though.

Note that the private API use inside WebEngine, which is removed via 
appstore_compliant configure switch, is a separate issue from sandboxing.

Regards, Alex.




On 04 May 2017, at 14:45, Morten Sørvig 
> wrote:

Hi,

Not sure if I can be of much help, but:

- This thread discusses and solves a similar problem: 
https://forum.qt.io/topic/49250/solved-qtwebengineprocess-not-working-in-sandboxed-application

- If this could be reduced to a simple sandboxed-app-with-helper-process test 
case (no QtWebEngine usage), that that’s something I could look at, and 
something we could eventually add an autotest for.


Morten


On 28 Apr 2017, at 18:49, Adalid Claure 
> wrote:

I have a desktop app that I have been trying to get onto the Mac App store but 
I have been having problems getting it to run in sandbox mode. For context I am 
(preferably) using Qt 5.8 running on macOS 10.11.6.

The crux seems to be QtWebEngineProcess.app refuses to run after I codesign the 
bundle. As a result, my QtWebEngine component doesn't load. I am using this 
QtWebEngine component as part of my app's UI.

When the app starts I see the following errors in Console:

kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup 
org.chromium.Chromium.rohitfork.20763
kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup 
org.chromium.Chromium.rohitfork.20763
QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] 
bootstrap_look_up: Permission denied (1100)
QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] 
bootstrap_look_up: Permission denied (1100)
kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) forbidden-sandbox-reinit

My build process is pretty straight forward:

1. Run macdeployqt on the app, using the -appstore-compliant.
2. Sign all of the Qt Frameworks and PlugIns individually with my app's 
entitlement file.
3. Sign QtWebEngineProcess.app with the following entitlements file:


http://www.apple.com/DTDs/PropertyList-1.0.dtd;>


   com.apple.security.app-sandbox
   
   com.apple.security.inherit
   



4. Call codesign on the overall MyProgram.app bundle with the entitlements file 
from Step 2.

I have tried numerous things all in combination with one another, including:

a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code (per 
the notes here: 
https://doc.qt.io/qt-5/qtwebengine-platform-notes.html#mac-app-store-compatibility)
b. use macdeployqt's -codesign, even though the binarys have to be signed a 
second time after this in order to apply the entitlements
c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to 
'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID.
d. tried linking with Qt 5.7
e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by Apple 
because:

---
Your app uses or references the following non-public API(s):

framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit'
: NSAccessibilityUnregisterUniqueIdForUIElement
: _NSAppendToKillRing
: _NSDrawCarbonThemeBezel
: _NSDrawCarbonThemeListBox
: _NSInitializeKillRing
: _NSNewKillRingSequence
: _NSPrependToKillRing
: _NSSetKillRingToYankedState
: _NSYankFromKillRing

framework: 
'/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices'
: CGSSetDenyWindowServerConnections
: CGSShutdownServerConnections
: CTFontCopyDefaultCascadeList

The use of non-public APIs is not permitted on the App Store as it can lead to 
a poor user experience should these APIs change.
---

I have chronicled a lot of this in this thread here 

Re: [Development] Getting QtWebEngineProcess.app to run in sandbox after being signed

[Adalid Claure]

Yeah, I saw that thread and unfortunately the suggestions there didn't help
me.

I attached a simple app and some other files to this bug I logged:
https://bugreports.qt.io/browse/QTBUG-60443

Thanks for your reply!

On Thu, May 4, 2017 at 8:45 AM, Morten Sørvig  wrote:

> Hi,
>
> Not sure if I can be of much help, but:
>
> - This thread discusses and solves a similar problem:
> https://forum.qt.io/topic/49250/solved-qtwebengineprocess-not-
> working-in-sandboxed-application
>
> - If this could be reduced to a simple sandboxed-app-with-helper-process
> test case (no QtWebEngine usage), that that’s something I could look at,
> and something we could eventually add an autotest for.
>
>
> Morten
>
>
> > On 28 Apr 2017, at 18:49, Adalid Claure  wrote:
> >
> > I have a desktop app that I have been trying to get onto the Mac App
> store but I have been having problems getting it to run in sandbox mode.
> For context I am (preferably) using Qt 5.8 running on macOS 10.11.6.
> >
> > The crux seems to be QtWebEngineProcess.app refuses to run after I
> codesign the bundle. As a result, my QtWebEngine component doesn't load. I
> am using this QtWebEngine component as part of my app's UI.
> >
> > When the app starts I see the following errors in Console:
> >
> > kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup
> org.chromium.Chromium.rohitfork.20763
> > kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup
> org.chromium.Chromium.rohitfork.20763
> > QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)]
> bootstrap_look_up: Permission denied (1100)
> > QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)]
> bootstrap_look_up: Permission denied (1100)
> > kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1)
> forbidden-sandbox-reinit
> >
> > My build process is pretty straight forward:
> >
> > 1. Run macdeployqt on the app, using the -appstore-compliant.
> > 2. Sign all of the Qt Frameworks and PlugIns individually with my app's
> entitlement file.
> > 3. Sign QtWebEngineProcess.app with the following entitlements file:
> >
> > 
> >  http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
> > 
> > 
> > com.apple.security.app-sandbox
> > 
> > com.apple.security.inherit
> > 
> > 
> > 
> >
> > 4. Call codesign on the overall MyProgram.app bundle with the
> entitlements file from Step 2.
> >
> > I have tried numerous things all in combination with one another,
> including:
> >
> > a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code
> (per the notes here: https://doc.qt.io/qt-5/qtwebengine-platform-notes.
> html#mac-app-store-compatibility)
> > b. use macdeployqt's -codesign, even though the binarys have to be
> signed a second time after this in order to apply the entitlements
> > c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to
> 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID.
> > d. tried linking with Qt 5.7
> > e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by
> Apple because:
> >
> > ---
> > Your app uses or references the following non-public API(s):
> >
> > framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/
> AppKit'
> > : NSAccessibilityUnregisterUniqueIdForUIElement
> > : _NSAppendToKillRing
> > : _NSDrawCarbonThemeBezel
> > : _NSDrawCarbonThemeListBox
> > : _NSInitializeKillRing
> > : _NSNewKillRingSequence
> > : _NSPrependToKillRing
> > : _NSSetKillRingToYankedState
> > : _NSYankFromKillRing
> >
> > framework: '/System/Library/Frameworks/ApplicationServices.framework/
> Versions/A/ApplicationServices'
> > : CGSSetDenyWindowServerConnections
> > : CGSShutdownServerConnections
> > : CTFontCopyDefaultCascadeList
> >
> > The use of non-public APIs is not permitted on the App Store as it can
> lead to a poor user experience should these APIs change.
> > ---
> >
> > I have chronicled a lot of this in this thread here (
> https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-
> app-store-with-qt-5-8-and-qtwebengineprocess) but the problem persists.
> >
> > Does anyone have any suggestions? Does anyone know of any apps on the
> Mac App Store that use QtWebEngine?
> >
> > Thanks.
> > ___
> > 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] Getting QtWebEngineProcess.app to run in sandbox after being signed

[Morten Sørvig]

Hi,

Not sure if I can be of much help, but:

- This thread discusses and solves a similar problem: 
https://forum.qt.io/topic/49250/solved-qtwebengineprocess-not-working-in-sandboxed-application

- If this could be reduced to a simple sandboxed-app-with-helper-process test 
case (no QtWebEngine usage), that that’s something I could look at, and 
something we could eventually add an autotest for.


Morten


> On 28 Apr 2017, at 18:49, Adalid Claure  wrote:
> 
> I have a desktop app that I have been trying to get onto the Mac App store 
> but I have been having problems getting it to run in sandbox mode. For 
> context I am (preferably) using Qt 5.8 running on macOS 10.11.6.
> 
> The crux seems to be QtWebEngineProcess.app refuses to run after I codesign 
> the bundle. As a result, my QtWebEngine component doesn't load. I am using 
> this QtWebEngine component as part of my app's UI.
> 
> When the app starts I see the following errors in Console:
> 
> kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) mach-lookup 
> org.chromium.Chromium.rohitfork.20763
> kernel[0]: Sandbox: QtWebEngineProce(20765) deny(1) mach-lookup 
> org.chromium.Chromium.rohitfork.20763
> QtWebEngineProcess[20764]: [0427/071053:ERROR:mach_broker_mac.mm(52)] 
> bootstrap_look_up: Permission denied (1100)
> QtWebEngineProcess[20765]: [0427/071053:ERROR:mach_broker_mac.mm(52)] 
> bootstrap_look_up: Permission denied (1100)
> kernel[0]: Sandbox: QtWebEngineProce(20764) deny(1) forbidden-sandbox-reinit
> 
> My build process is pretty straight forward:
> 
> 1. Run macdeployqt on the app, using the -appstore-compliant.
> 2. Sign all of the Qt Frameworks and PlugIns individually with my app's 
> entitlement file.
> 3. Sign QtWebEngineProcess.app with the following entitlements file:
> 
> 
>  "http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
> 
> 
> com.apple.security.app-sandbox
> 
> com.apple.security.inherit
> 
> 
> 
> 
> 4. Call codesign on the overall MyProgram.app bundle with the entitlements 
> file from Step 2.
> 
> I have tried numerous things all in combination with one another, including:
> 
> a. built QtWebEngine using WEBENGINE_CONFIG+=use_appstore_compliant_code (per 
> the notes here: 
> https://doc.qt.io/qt-5/qtwebengine-platform-notes.html#mac-app-store-compatibility)
> b. use macdeployqt's -codesign, even though the binarys have to be signed a 
> second time after this in order to apply the entitlements
> c. sign QtWebEngineProcess.app with CFBundleIdentifier equal to 
> 'com.qt-project.Qt.QtWebEngineProcess' and with my own app's bundle ID.
> d. tried linking with Qt 5.7
> e. tried linking with Qt 5.6.2 which *did* run but then gets rejected by 
> Apple because:
> 
> ---
> Your app uses or references the following non-public API(s):
> 
> framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit'
> : NSAccessibilityUnregisterUniqueIdForUIElement
> : _NSAppendToKillRing
> : _NSDrawCarbonThemeBezel
> : _NSDrawCarbonThemeListBox
> : _NSInitializeKillRing
> : _NSNewKillRingSequence
> : _NSPrependToKillRing
> : _NSSetKillRingToYankedState
> : _NSYankFromKillRing
> 
> framework: 
> '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices'
> : CGSSetDenyWindowServerConnections
> : CGSShutdownServerConnections
> : CTFontCopyDefaultCascadeList
> 
> The use of non-public APIs is not permitted on the App Store as it can lead 
> to a poor user experience should these APIs change.
> ---
> 
> I have chronicled a lot of this in this thread here 
> (https://forum.qt.io/topic/78518/sandbox-app-for-the-mac-app-store-with-qt-5-8-and-qtwebengineprocess)
>  but the problem persists. 
> 
> Does anyone have any suggestions? Does anyone know of any apps on the Mac App 
> Store that use QtWebEngine?
> 
> Thanks.
> ___
> 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] Clarification needed on a crash caused by ignoring ownership of an object

[Andy Shaw]

Thanks Marc, that covers what I needed to know to make a decision ☺

Andy

Development på vegne av Marc Mutz 
 skrev følgende den 04.05.2017, 10.08:

On Thursday 04 May 2017 09:58:45 Andy Shaw wrote:
> Hi,
> 
> I am trying to determine what we should be doing inside Qt in a certain
> case. When a QUndoCommand is deleted after it has been given another
> QUndoCommand as a parent it will cause a crash since the parent has not
> been informed that the child was deleted. The documentation for
> QUndoCommand is explicit on the fact that when it has a parent the
> ownership of the QUndoCommand is transferred to its parent. As such I
> would not expect it to be possible to delete the child directly anymore as
> a result as we no longer own it.
> 
> So the question is, since it is still a crash, should we still be
> accounting for this in the Qt code so as to prevent the crash or is it a
> case of it is documented to transfer ownership and as such we don’t want
> to protect against it being deleted out of Qt’s hands?

Seeing as about half of the ubsan reports are about shutdown sequences of 
object hierarchies which allow parent-owned children to be deleted by the 
user, I'm tempted to say: add an assert (set a flag when the parent deletes 
a 
child, check that the flag is set in the child's dtor).

OTOH, QObject parent-child relationships, and QTreeWidgetItems set a strong 
precedent.

I'd decide based on how much complexity this adds to the implementation, 
but 
if you prepare a patch, the pressure to merge it is going to be a great 
one. 
The work is already done, after all. So, please decide yourself. You have 
my 
blessing to close as WONTFIX, or else enable the new use-case if it's not 
too 
complex (a very subjective criterion, I agree).

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
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] Clarification needed on a crash caused by ignoring ownership of an object

[Marc Mutz]

On Thursday 04 May 2017 09:58:45 Andy Shaw wrote:
> Hi,
> 
> I am trying to determine what we should be doing inside Qt in a certain
> case. When a QUndoCommand is deleted after it has been given another
> QUndoCommand as a parent it will cause a crash since the parent has not
> been informed that the child was deleted. The documentation for
> QUndoCommand is explicit on the fact that when it has a parent the
> ownership of the QUndoCommand is transferred to its parent. As such I
> would not expect it to be possible to delete the child directly anymore as
> a result as we no longer own it.
> 
> So the question is, since it is still a crash, should we still be
> accounting for this in the Qt code so as to prevent the crash or is it a
> case of it is documented to transfer ownership and as such we don’t want
> to protect against it being deleted out of Qt’s hands?

Seeing as about half of the ubsan reports are about shutdown sequences of 
object hierarchies which allow parent-owned children to be deleted by the 
user, I'm tempted to say: add an assert (set a flag when the parent deletes a 
child, check that the flag is set in the child's dtor).

OTOH, QObject parent-child relationships, and QTreeWidgetItems set a strong 
precedent.

I'd decide based on how much complexity this adds to the implementation, but 
if you prepare a patch, the pressure to merge it is going to be a great one. 
The work is already done, after all. So, please decide yourself. You have my 
blessing to close as WONTFIX, or else enable the new use-case if it's not too 
complex (a very subjective criterion, I agree).

Thanks,
Marc

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

[Development] Clarification needed on a crash caused by ignoring ownership of an object

[Andy Shaw]

Hi,

I am trying to determine what we should be doing inside Qt in a certain case. 
When a QUndoCommand is deleted after it has been given another QUndoCommand as 
a parent it will cause a crash since the parent has not been informed that the 
child was deleted. The documentation for QUndoCommand is explicit on the fact 
that when it has a parent the ownership of the QUndoCommand is transferred to 
its parent. As such I would not expect it to be possible to delete the child 
directly anymore as a result as we no longer own it. 

So the question is, since it is still a crash, should we still be accounting 
for this in the Qt code so as to prevent the crash or is it a case of it is 
documented to transfer ownership and as such we don’t want to protect against 
it being deleted out of Qt’s hands?

Andy

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

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Heikki Halmet]

Hi,

First of all thank you for all these comments!


There was few changes to the ‘proposal changes list’ and here is the summary:

32-bit iOS: will be dropped from CI and will be no longer supported by Qt
OSX 10.10: will be dropped from CI, but will be supported by Qt
GCC 7: When released it will be tested with some linux distro in CI
Clang 4: Do we really need this to be tested with Linux in CI? If yes, then 
which configuration it will be replaced?



Br
Heikki Halmet






-Original Message-
From: Development 
[mailto:development-bounces+heikki.halmet=qt...@qt-project.org] On Behalf Of 
Tuukka Turunen
Sent: 2. toukokuuta 2017 10:23
To: Jake Petroules ; Lars Knoll 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal for Qt 5.10 platforms and configurations 
changes


Hi,

While I do agree that having a platform in CI and supporting it for those who 
have purchased support are not 1:1, in case of dropping the 32-bit iOS from CI 
for Qt 5.10 it also means that this configuration should no longer be used and 
not be supported. I do not see much problems with that as we continue to 
support 32 bit iOS for earlier platforms (until Apple drops it) and the 32 bit 
iOS devices are already quite old.

Yours,

Tuukka


On 28/04/2017, 19.58, "Jake Petroules"  wrote:


> On Apr 27, 2017, at 11:28 PM, Lars Knoll  wrote:
> 
> 
>> On 27 Apr 2017, at 16:59, Jake Petroules  wrote:
>> 
>>> 
>>> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen  
wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> Related to the Apple platforms, could we consider the following for Qt 
5.10:
>>> - Drop the older iPhone support by removing ARMv7 from iOS 
(http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf)
>>> - Consider also dropping ARMv7s support, which would allow dropping 
i386 simulator support
>> 
>> I really don't like how we use the term "support" in these emails 
because it's rather misleading. We use it to mean "tested in CI", whereas I 
(and most of the world, as far as I can tell) read it as "the code exists and 
is functional". "Removing support" to me means actively removing the code which 
makes something functional.
> 
> Agree, there is a difference between the two. 
> 
> What I think we should however do for 5.10 is remove 32bit support for 
iOS from CI and our binary packages. And that means that things will be 
untested on 32bit iOS, and thus is likely to break at some point.

I think 32-bit support on iOS is kind of unlikely to break accidentally, 
but I agree we should remove it from our binary packages. The iPhone 5 is dead.

>> 
>> As an Open Source project, we need to keep in mind that dropping first 
party "support" for something means little to nothing unless we actually delete 
the associated code as well and refuse patches to re-add it, because people can 
always build their own copy of Qt, and commercial support will obviously still 
answer queries for most definitions of "unsupported", making the term 
"unsupported" a little meaningless. Perhaps we can start using the term "tier 1 
support" as a synonym for what we actually mean by "support", in order to be 
more clear? I really liked the notion of tiered support that we used to have 
but it seems to have gone missing…
> 
> For the commercial version, it’s to a large extent up to TQtC to define 
the support offering. The open source project anyway does not offer any 
official support for the Qt versions released. All you can do is ask on the 
mailing lists or file a bug report and hope for the best. Or of course sit 
down, fix it yourself and submit a patch :)

My point was that if a commercial customer goes to support with a bug in a 
32-bit build of Qt for iOS, support won't say "we do not support that, go 
away". They will fix the problem, regardless of the fact that it isn't part of 
a reference configuration.

If a customer sets the minimum deployment target of Qt for iOS to 5.0 and 
then goes to support saying Qt doesn't work, support WILL tell them "we do not 
support that (because we deliberately broke it), we can't help you and you'll 
have to talk to Services and pay money if you want it working that badly".

That's the real-world outcome, which is why I don't like using the term 
"supported" as a synonym for "is a reference configuration in CI".

A reference configuration in CI always constitutes something that is 
supported. However, something that's supported is not necessarily a reference 
configuration in CI. We should make this clear to our users by not using the 
term "supported" in a misleading way.

> 
>> 
>> Something like the following seems nice:
>> Tier 1 - the most rigorously tested 

Re: [Development] QtWebKit is coming back (part 2)

[Jani Heikkinen]

> -Original Message-
> From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
> project.org] On Behalf Of Konstantin Tokarev
> Sent: keskiviikkona 3. toukokuuta 2017 18.14
> To: Adalid Claure 
> Cc: development@qt-project.org
> Subject: Re: [Development] QtWebKit is coming back (part 2)
> 
> 
> 
> 03.05.2017, 18:05, "Adalid Claure" :
> > Does this mean that at some point this new QtWebKit would be packaged
> with Qt (like in the old days)?
> 
> I hope for this (if possible, in 5.9 with Technology preview status ;)
I don't think adding new TP in 5.9 at this point isn't that wise anymore. We 
have agreed to get all these new submodules (also TP ones) in before FF and so 
on 5.10 is first option. 

br,
Jani

> 
> Also note that you can already get binaries compatible with Qt 5.8.0 from
> 
> https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5
> 
> (but note that TP5 does not include QML API yet)
> 
> They are built in Coin just like official binaries packaged in Qt SDK.
> 
> >
> > On Wed, May 3, 2017 at 10:25 AM, Sergio Martins
>  wrote:
> >> On 2017-05-03 15:02, Konstantin Tokarev wrote:
> >> Remaining question is versioning. While it's fine to dub current
> >> release "5.9" (but not 5.0, because we will have another WebKit
> >> update in 5.10 time frame), using Qt versions in QtWebKit has downsides:
> >>
> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
> >> or is updated 2. It makes people believe that QtWebKit 5.N should be
> >> used with Qt 5.N only. QtWebKit supports wide range of Qt versions
> >> (starting from
> >> 5.2 as of now), and can be used e.g. as security update in Linux
> >> distro that does not normally update Qt version during its life cycle.
> >>
> >> Any comments?
> >>
> >> If Qt and QtWebKit will have different release schedules then that
> numbering would indeed confuse people.
> >>
> >> Have you thought about an LTS version too ? What would LTS mean, for
> QtWebKit ? I think during the LTS lifetime we would still need to update the
> inner WebKit, for security reasons, (that even happened for QtWebEngine in
> a 5.6.x patch release).
> >>
> >> Thanks for your efforts on this!
> >>
> >> Regards,
> >> --
> >> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> >> Klarälvdalens Datakonsult AB, a KDAB Group company
> >> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB -
> The
> >> Qt, C++ and OpenGL Experts
> >>
> >> ___
> >> 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
> 
> 
> --
> Regards,
> Konstantin
> ___
> 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