i found what caused the issue:
I accidentally also linked some other code to the application in which
a static initialization of a QNetworkAccessManger happened.
This also explains the different behavior between release and debug mode.
>> QEventLoop: Cannot be used without QApplication
>
> S
Environment:
windows 7 Ultimate
msys2
g++ : (Rev5, Built by MSYS2 project) 4.9.2
Compile-timethe followingerror:
tools/qsimd.cpp:36:22: fatal error: QByteArray: No such file or directory
#include
^
compilation terminated.
Makefile.Release:16625: recipe for target '.obj/
qtbase integrations used to take around 3 hours as recently as two weeks ago.
In the past week, I've caught several integrations lasting more than 6 hours.
The one currently running is integrating a single commit and has been running
for 6h30. I've seen one for 12 hours.
Is this a timeout not c
On 2015-04-02 12:27, René J.V. Bertin wrote:
> On Thursday April 02 2015 11:58:58 Matthew Woehlke wrote:
>> Do you honestly expect that every Qt install on a Linux-based platform
>> will also have the base KF5 libraries installed? Even on a machine that
>
> No, and I didn't say that. I did mention
On Thursday April 02 2015 11:58:58 Matthew Woehlke wrote:
> Do you honestly expect that every Qt install on a Linux-based platform
> will also have the base KF5 libraries installed? Even on a machine that
No, and I didn't say that. I did mention "reasonably small" and "standalone",
meaning not r
On 2015-04-02 10:38, René J.V. Bertin wrote:
> On Thursday April 02 2015 09:46:29 Matthew Woehlke wrote:
>> It may be too late to change this for Qt 4, but please, let's get it
>> right for Qt 5 :-).
>
> With KF5 aiming to be "just" a modular set of extensions to Qt 5, why
> not leave it like that
On Thursday April 02 2015 09:46:29 Matthew Woehlke wrote:
> It may be too late to change this for Qt 4, but please, let's get it
> right for Qt 5 :-).
With KF5 aiming to be "just" a modular set of extensions to Qt 5, why not leave
it like that, and just push the KDE devs to implement the file di
On 2015-04-02 09:11, Friedemann Kleint wrote:
> the behavior of the widgets-based dialog is equivalent to Qt 4.X and
> that was the end of the story back then. As reading material for Easter,
> I pushed up a proposal to gerrit (
> https://codereview.qt-project.org/#/c/109815/ ). I expect KDE 5 w
Hi,
the behavior of the widgets-based dialog is equivalent to Qt 4.X and
that was the end of the story back then. As reading material for Easter,
I pushed up a proposal to gerrit (
https://codereview.qt-project.org/#/c/109815/ ). I expect KDE 5 will
(again) provide a spectactular native file d
On Thu, Apr 02, 2015 at 10:09:18AM +, Hirvonen Olli wrote:
> Thanks Kai for noticing...Mika (CC) tries to find a reason and fix.
>
that should be fixed now, at least for the time being.
> -Olli
>
> -Original Message-
> From: Koehne Kai
> Sent: 2. huhtikuuta 2015 12:03
> To: Hirvonen
Thanks Kai for noticing...Mika (CC) tries to find a reason and fix.
-Olli
-Original Message-
From: Koehne Kai
Sent: 2. huhtikuuta 2015 12:03
To: Hirvonen Olli; development@qt-project.org
Subject: git://code.qt.io availability
Hi,
Since a few days code.qt.io seems to be quite unreliable
Hi,
Since a few days code.qt.io seems to be quite unreliable: Fetching changes via
git:// often fail with "fatal: read error: Invalid argument" (Windows) or
"fatal: read error: Connection reset by peer" (Linux).
Is someone already looking into this? Should we rather clone from the github
mirro
Hello,
it has been quite some time since this thread, but yesterday i tried the
approach using no_desktop just to find out, the the qtsvg imageformat plugin,
has ( of course) a dependency on qtsvg, which in turn does also depend on
widgets.
Ok so i thought i use -no-widgets when configuring, but
13 matches
Mail list logo
