Hi,
I believe Akseli was making progress on that front. Can you fill us briefly in
on the status?
Thanks :)
Simon
> On 5. May 2017, at 00:16, Konstantin Tokarev wrote:
>
>
>
> 05.05.2017, 01:11, "Thiago Macieira" :
>> Em quinta-feira, 4 de maio de 2017, às 14:22:55 PDT, Konstantin Tokarev
>
> On 4 May 2017, at 16:51, Sergio Martins wrote:
>
> 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
> -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
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
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
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
>> issuin
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, howeve
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 li
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 "
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.
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
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
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
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
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
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
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 i
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 explai
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 aroun
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
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 su
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.c
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), u
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
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 the
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)
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
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 g
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
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 be
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 downsid
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 privat
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
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 us
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
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
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 i
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
> -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 b
39 matches
Mail list logo
