[Development] Gerrit problems fixed (?)

2017-12-21 Thread Tony Sarajärvi
Hi again!

The gerrit problems we've seen (example below (pardon for top posting with 
Outlook)) are potentially fixed. The problem was found to be in the AWS VM. 
Following actions were made to remedy the situation:

  *   Port range increased to allow more connections
  *   Mount options adjusted optimizing file access
  *   I/O scheduler is now 'noop'

With these changes the symptoms are for now gone. If they start appearing 
again, just hit reply to this thread and let's see if we can reproduce and fix 
it.

Thank you,
-Tony


From: Tony Sarajärvi
Sent: keskiviikko 13. joulukuuta 2017 21.39
To: 'development@qt-project.org' 
Subject: RE: Builds missing qmake?

Hi again.

Should have told you this as well. When you see this error message coming from 
the CI:
"Could not access requested repository (: RAN: /usr/bin/git 
--git-dir=/home/vmbuilder/ci-working-dir/git-repos/qt-project/qt/qtwebview 
--no-pager fetch --tags origin 
+refs/builds/qtci/5.9/1513182815:refs/builds/qtci/5.9/1513182815 STDOUT: 
packet_write_wait: Connection to 54.229.21.112 port 29418: Broken pipe fatal: 
Could not read from remote repository. Please make sure you have the correct 
access rights and the repository exists. STDERR:"

It means that Coin is unable to retrieve needed sources from codereview. Again, 
as of now we don't know the root cause for this. We can produce this even 
outside Coin, so it's a problem outside our CI. We are investigating where and 
why the connections are lost.

When this happens you don't have to contact us however. Just restage your 
commit and the next time around the sources might be retrieved.

I apologize for the inconvenience
-Tony

From: Tony Sarajärvi
Sent: keskiviikko 13. joulukuuta 2017 11.26
To: 'development@qt-project.org' 
mailto:development@qt-project.org>>
Subject: Builds missing qmake?

Hi

If you stumble upon a problem in your build where the error message says that 
it can't find qmake, contact us maintaining the CI immediately. It's not a 
random failure in such that it goes away by restaging a few times. It means 
that for some reason (still unclear) we have a pointer indicating where the 
binaries should be, but they aren't. So they are never even uncompressed. But 
we can't really fail the build on missing artifacts, since we have no way of 
knowing if those binaries are optional or not. The error above clearly says 
that qtbase binaries are now uncompressed, hence the missing qmake, but we 
don't want to hard code all the really dependent packages for every module. 
Instead, we're trying to figure out why those binaries are missing in the first 
place.

So, qmake missing error -> contact us. We are needed to fix it currently.

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


Re: [Development] CI is suffering from problems

2017-12-21 Thread Tony Sarajärvi
Hi

This problem was fixed for now. We have the CI running again since yesterday 
afternoon. The system needed a cold boot of the server to update all disk 
related info after our cleanup. Free space etc were reported incorrectly before 
that.

To avoid this, we should never ever let the disk get 100% full, and we have to 
be more careful with that. Monitoring didn’t help here as we ignored the 
warnings we received ☹

-T
From: Tony Sarajärvi
Sent: torstai 21. joulukuuta 2017 14.19
To: development@qt-project.org
Subject: CI is suffering from problems

Hi

You have probably already noticed this, but here’s an email notifying you that 
we’re on it. Our OpenNebula isn’t able to clone any new virtual machines, 
complaining that the disk is full even though it isn’t. As said…we continue 
investigating.

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


[Development] Qt 5.11 feature freeze is getting closer: New submodules in Qt 5.11?

2017-12-21 Thread Jani Heikkinen
Hi all,

There is only a bit more than a month to Qt 5.11 feature freeze, see 
https://wiki.qt.io/Qt_5.11_Release . So at this point we should already know if 
there will be some new submodule modules in Qt 5.11. We are doing packaging 
confs etc for 5.11 now so please inform me immediately if there will be some 
new in. And of course get the new submodule in qt5 as soon as possible; those 
really needs to be in before we start soft branching!

br,
Jani




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


Re: [Development] 32bit linux build of qt5.10.0 w/ webengine

2017-12-21 Thread Kevin Kofler
Thiago Macieira wrote:
> To build? At least 8 GB of RAM and please use a 64-bit toolchain. You may
> compile for 32-bit, but you need to use a 64-bit linker executable.

I haven't tried 5.10.0 yet, but 5.9.3 built fine with the 32-bit toolchains 
we have in our Fedora 32-bit buildroots (i686 and armv7hl). All packages in 
Fedora are natively built, not cross-built, which means that 32-bit binaries 
will necessarily be built with a 32-bit linker. If this stops/stopped 
working, we will no longer be able to ship QtWebEngine on 32-bit 
architectures in Fedora.

Kevin Kofler

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


Re: [Development] 32bit linux build of qt5.10.0 w/ webengine

2017-12-21 Thread Thiago Macieira
On quinta-feira, 21 de dezembro de 2017 18:57:15 -02 Toan Pham wrote:
> On my t2 sandbox environment, It only has 3G of RAM and that webengine
> build stopped because it ran out of memory.
> 
> Does anyone know the minimal memory requirement to build qt w/ webengine.

To build? At least 8 GB of RAM and please use a 64-bit toolchain. You may 
compile for 32-bit, but you need to use a 64-bit linker executable.

-- 
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] 32bit linux build of qt5.10.0 w/ webengine

2017-12-21 Thread Toan Pham
Sorry for so much email noise,

On my t2 sandbox environment, It only has 3G of RAM and that webengine
build stopped because it ran out of memory.

Does anyone know the minimal memory requirement to build qt w/ webengine.

thanks,







[10013] 0 10013 1785  102   1   0 0 sshd
[10015] 0 10015  965   74   7   0 0 bash
[10019] 0 10019 1785   93   2   0 0 sshd
[10023] 0 10023  965   75   7   0 0 bash
[29587] 0 29587  923   36   0   0 0 debug.sh
[29593] 0 29593  935  245   1   0 0 bash
[24417] 0 24417  923   34   0   0 0 debug.sh
[24418] 0 24418  935  242   1   0 0 bash
[32263] 0 32263 2441 1961   2   0 0 make
[32265] 0 32265  663   60   3   0 0 sh
[32267] 0 32267 2428 1971   4   0 0 make
[32285] 0 32285  663   59   5   0 0 sh
[32287] 0 32287 2355 1889   6   0 0 make
[32294] 0 32294  663   60   7   0 0 sh
[32296] 0 32296 2408 1952   0   0 0 make
[32297] 0 32297  663   60   1   0 0 sh
[32298] 0 322981610915287   2   0 0 ninja
[ 2599] 0  2599  635   39   3   0 0 g++
[ 2601] 0  2601   10444197898   1   0 0 cc1plus
[ 2602] 0  2602 1337  638   7   0 0 as
[ 2607] 0  2607  635   38   3   0 0 g++
[ 2609] 0  2609   110143   103510   1   0 0 cc1plus
[ 2610] 0  2610 1337  638   5   0 0 as
[ 2611] 0  2611  635   38   4   0 0 g++
[ 2613] 0  2613   106617   100108   1   0 0 cc1plus
[ 2614] 0  2614 1337  638   7   0 0 as
[ 2615] 0  2615  635   39   4   0 0 g++
[ 2617] 0  2617   106756   100048   1   0 0 cc1plus
[ 2618] 0  2618 1337  637   5   0 0 as
[ 2623] 0  2623  635   39   3   0 0 g++
[ 2625] 0  26259687790704   1   0 0 cc1plus
[ 2626] 0  2626 1337  638   5   0 0 as
Out of memory: Kill process 2609 (cc1plus) score 84 or sacrifice child
Killed process 2609 (cc1plus) total-vm:440572kB, anon-rss:413632kB,
file-rss:408kB


On Thu, Dec 21, 2017 at 3:30 PM, Toan Pham  wrote:

>
> Hi all,
>
>
> How do I add an include path (/usr/X11/include) to chromium build.
>
> Not sure why qtwebengine did not detect include path /usr/X11/include
> before starting the build.  thanks
>
>
>
>
> [1878/11462] CXX obj/skia/skia/SkFontConfigInterface_direct.o
> FAILED: obj/skia/skia/SkFontConfigInterface_direct.o
> /TOOLCHAIN/build/nicebox-9.0-trunk-nicebox-x86-pentium4-
> linux/TOOLCHAIN/tools.chroot/wrapper/g++ -MMD -MF obj/skia/skia/
> SkFontConfigInterface_direct.o.d -DV8_DEPRECATION_WARNINGS -DUSE_UDEV
> -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DDISABLE_NACL
> -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL
> -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED -DTOOLKIT_QT
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNDEBUG
> -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 
> -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS
> -DSK_HAS_PNG_LIBRARY -DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY
> -DSK_SUPPORT_GPU=1 -DSK_GAMMA_EXPONENT=1.2 -DSK_GAMMA_CONTRAST=0.2
> -DSK_DEFAULT_FONT_CACHE_LIMIT=20971520 -DUSE_LIBJPEG_TURBO=1
> -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_STATIC_IMPLEMENTATION
> -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -Igen
> -I../../3rdparty/chromium -I../../3rdparty/chromium/skia/config
> -I../../3rdparty/chromium/skia/ext 
> -I../../3rdparty/chromium/third_party/skia/include/c
> -I../../3rdparty/chromium/third_party/skia/include/config
> -I../../3rdparty/chromium/third_party/skia/include/core
> -I../../3rdparty/chromium/third_party/skia/include/effects
> -I../../3rdparty/chromium/third_party/skia/include/encode
> -I../../3rdparty/chromium/third_party/skia/include/images
> -I../../3rdparty/chromium/third_party/skia/include/lazy
> -I../../3rdparty/chromium/third_party/skia/include/pathops
> -I../../3rdparty/chromium/third_party/skia/include/pdf
> -I../../3rdparty/chromium/third_party/skia/include/pipe
> -I../../3rdparty/chromium/third_party/skia/include/ports
> -I../../3rdparty/chromium/third_party/skia/include/utils
> -I../../3rdparty/chromium/third_party/skia/third_party/vulkan
> -I../../3rdparty/chromium/third_party/skia/include/gpu
> -I../../3rdparty/chromium/third_party/skia/src/gpu
> -I../../3rdparty/chromium/third_party/skia/src/sksl
> -I../../3rdparty/chromium/third_party/skia/include/private
> -I../../3r

Re: [Development] 32bit linux build of qt5.10.0 w/ webengine

2017-12-21 Thread Toan Pham
Hi all,


How do I add an include path (/usr/X11/include) to chromium build.

Not sure why qtwebengine did not detect include path /usr/X11/include
before starting the build.  thanks




[1878/11462] CXX obj/skia/skia/SkFontConfigInterface_direct.o
FAILED: obj/skia/skia/SkFontConfigInterface_direct.o
/TOOLCHAIN/build/nicebox-9.0-trunk-nicebox-x86-pentium4-linux/TOOLCHAIN/tools.chroot/wrapper/g++
-MMD -MF obj/skia/skia/SkFontConfigInterface_direct.o.d
-DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1
-DUSE_X11=1 -DNO_TCMALLOC -DDISABLE_NACL -DFULL_SAFE_BROWSING
-DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD
-DFIELDTRIAL_TESTING_ENABLED -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNDEBUG -DNVALGRIND
-DDYNAMIC_ANNOTATIONS_ENABLED=0 -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS
-DSK_HAS_PNG_LIBRARY -DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY
-DSK_SUPPORT_GPU=1 -DSK_GAMMA_EXPONENT=1.2 -DSK_GAMMA_CONTRAST=0.2
-DSK_DEFAULT_FONT_CACHE_LIMIT=20971520 -DUSE_LIBJPEG_TURBO=1
-DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_STATIC_IMPLEMENTATION
-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -Igen
-I../../3rdparty/chromium -I../../3rdparty/chromium/skia/config
-I../../3rdparty/chromium/skia/ext
-I../../3rdparty/chromium/third_party/skia/include/c
-I../../3rdparty/chromium/third_party/skia/include/config
-I../../3rdparty/chromium/third_party/skia/include/core
-I../../3rdparty/chromium/third_party/skia/include/effects
-I../../3rdparty/chromium/third_party/skia/include/encode
-I../../3rdparty/chromium/third_party/skia/include/images
-I../../3rdparty/chromium/third_party/skia/include/lazy
-I../../3rdparty/chromium/third_party/skia/include/pathops
-I../../3rdparty/chromium/third_party/skia/include/pdf
-I../../3rdparty/chromium/third_party/skia/include/pipe
-I../../3rdparty/chromium/third_party/skia/include/ports
-I../../3rdparty/chromium/third_party/skia/include/utils
-I../../3rdparty/chromium/third_party/skia/third_party/vulkan
-I../../3rdparty/chromium/third_party/skia/include/gpu
-I../../3rdparty/chromium/third_party/skia/src/gpu
-I../../3rdparty/chromium/third_party/skia/src/sksl
-I../../3rdparty/chromium/third_party/skia/include/private
-I../../3rdparty/chromium/third_party/skia/include/client/android
-I../../3rdparty/chromium/third_party/skia/src/codec
-I../../3rdparty/chromium/third_party/skia/src/core
-I../../3rdparty/chromium/third_party/skia/src/image
-I../../3rdparty/chromium/third_party/skia/src/images
-I../../3rdparty/chromium/third_party/skia/src/opts
-I../../3rdparty/chromium/third_party/skia/src/pdf
-I../../3rdparty/chromium/third_party/skia/src/ports
-I../../3rdparty/chromium/third_party/skia/src/shaders
-I../../3rdparty/chromium/third_party/skia/src/shaders/gradients
-I../../3rdparty/chromium/third_party/skia/src/sfnt
-I../../3rdparty/chromium/third_party/skia/src/utils
-I../../3rdparty/chromium/third_party/skia/src/lazy
-I../../3rdparty/chromium/third_party/skia/src/effects/gradients
-I../../3rdparty/chromium/third_party/libwebp/src -I/usr/include/freetype2
-I../../3rdparty/chromium/third_party/libjpeg_turbo
-I../../3rdparty/chromium/third_party/libpng
-I../../3rdparty/chromium/third_party/zlib
-I../../3rdparty/chromium/third_party/icu/source/common
-I../../3rdparty/chromium/third_party/icu/source/i18n
-I../../3rdparty/chromium/third_party/sfntly/src/cpp/src
-fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector
-Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__=
-funwind-tables -fPIC -pipe -pthread -m32 -msse2 -mfpmath=sse -mmmx
-fomit-frame-pointer -g0 -fvisibility=hidden -Wno-unused-local-typedefs
-Wno-maybe-uninitialized -Wno-missing-field-initializers
-Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections
-std=gnu++11 -fno-rtti -fno-exceptions -fvisibility-inlines-hidden
-Wno-narrowing -c
../../3rdparty/chromium/third_party/skia/src/ports/SkFontConfigInterface_direct.cpp
-o obj/skia/skia/SkFontConfigInterface_direct.o
In file included from
../../3rdparty/chromium/third_party/skia/src/ports/SkFontConfigInterface_direct.cpp:13:0:
../../3rdparty/chromium/third_party/skia/src/ports/SkFontConfigInterface_direct.h:12:35:
fatal error: fontconfig/fontconfig.h: No such file or directory
 #include 
   ^
compilation terminated.
[1887/11462] CXX obj/skia/skia/SkSLSPIRVCodeGenerator.o
ninja: build stopped: subcommand failed.
make[3]: *** [run_ninja] Error 1
make[3]: Leaving directory
`/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core'
make[2]: *** [sub-gn_run-pro-make_first] Error 2
make[2]: Leaving directory
`/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core'
make[1]: *** [sub-core-make_first] Error 2
make[1]: Leaving directory
`/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src'


On Tue, Dec 19, 2017 at 4:15 PM, Toan Pham  wrote:

> Hi all,
>
> I just found o

Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework

2017-12-21 Thread Thiago Macieira
On quinta-feira, 21 de dezembro de 2017 14:53:35 -02 René J.V. Bertin wrote:
> I'm pretty sure `sysctl hw.model` doesn't return anything that starts with
> Mac when you're not on a Mac though?

Entirely irrelevant, since it would tell you what you're running on, not what 
you're compiling for.

-- 
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] Reporting errors for powershell scripts executed by Coin

2017-12-21 Thread Konstantin Tokarev
Hi all,

AFAIU, some time ago Coin considered ps1 script to be failed its exit code was 
non-null (e.g, Exit(1) certainly aborted further provisioning process).

Now I see that Exit(1) is ignored (see [1]). What is the correct way now, throw 
exception?

[1] 
https://testresults.qt.io/coin/api/results/provisioning/qtci-windows-10-x86_64-10-f8e8db/provision_1513869138/log.txt.gz

Words "conan exited with code 1" are printed before script does Exit(1)



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


Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework

2017-12-21 Thread René J . V . Bertin
On Thursday December 21 2017 20:19:03 Konstantin Tokarev wrote:

>> I'm pretty sure `sysctl hw.model` doesn't return anything that starts with 
>> Mac when you're not on a Mac though?
>
>Are you trying to distinguish it from PureDarwin?

No, in theory that command should always return the identification of the 
actual hardware it's running on.
(I thought that project was dead, apparently not, cool, but will Qt support 
it?).

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


Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework

2017-12-21 Thread Konstantin Tokarev


21.12.2017, 19:53, "René J.V. Bertin" :
> On Thursday December 21 2017 16:25:02 Jake Petroules wrote:
>
>>  > Possibly: just `uname` returns Darwin. That should certainly work for the 
>> desktop OS, but I have no way of checking what it returns on other Apple OSes
>>
>>  they all return "Darwin"
>
> Figures...
>
>>  > (and if the Carbon.framework exists there).
>>
>>  it does not :)
>
> I'm pretty sure `sysctl hw.model` doesn't return anything that starts with 
> Mac when you're not on a Mac though?

Are you trying to distinguish it from PureDarwin?

>
> R

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


Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework

2017-12-21 Thread René J . V . Bertin
On Thursday December 21 2017 16:25:02 Jake Petroules wrote:

> > Possibly: just `uname` returns Darwin. That should certainly work for the 
> > desktop OS, but I have no way of checking what it returns on other Apple 
> > OSes
> 
> they all return "Darwin"

Figures...

> > (and if the Carbon.framework exists there).
> 
> it does not :)

I'm pretty sure `sysctl hw.model` doesn't return anything that starts with Mac 
when you're not on a Mac though?

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


Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework

2017-12-21 Thread Jake Petroules


> On Dec 21, 2017, at 3:57 AM, René J.V. Bertin  wrote:
> 
> On Thursday December 21 2017 13:47:34 Konstantin Tokarev wrote:
> 
>> Check uname maybe?
> 
> Possibly: just `uname` returns Darwin. That should certainly work for the 
> desktop OS, but I have no way of checking what it returns on other Apple OSes

they all return "Darwin"

> (and if the Carbon.framework exists there).

it does not :)

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

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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


Re: [Development] CI is suffering from problems

2017-12-21 Thread Liang Qi
both are known and fixes are available.

https://codereview.qt-project.org/#/c/215113/
https://codereview.qt-project.org/#/c/215046/

— Liang

> On 21 Dec 2017, at 14:17, Ulf Hermann  wrote:
> 
>> You have probably already noticed this, but here’s an email notifying
>> you that we’re on it. Our OpenNebula isn’t able to clone any new virtual
>> machines, complaining that the disk is full even though it isn’t. As
>> said…we continue investigating.
> 
> In addition to that we suddenly get failures when compiling QtCore and 
> QtNetwork, even if nothing has changed there:
> 
>> Module "qt/qtbase" (9ec8da01004481027df83361b998b24c63ab5a6d) The make 
>> execution failed. The CI rejected the staged commits due to the 
>> beforementioned reason. Possible reason could be flakiness in the system, 
>> but could also be a bug in one of the commits.:
>> /home/qt/work/qt/qtbase/src/corelib/global/qfloat16_f16c.c:61: undefined 
>> reference to `_mm256_cvtps_ph'
>> /home/qt/work/qt/qtbase/src/corelib/global/qfloat16_f16c.c:76: undefined 
>> reference to `_mm256_cvtph_ps'
>> Makefile:1152: recipe for target '../../lib/libQt5Core.so.5.11.0' failed
>> make[2]: *** [../../lib/libQt5Core.so.5.11.0] Error 1
>> make[1]: *** [sub-corelib-make_first] Error 2
>> make: *** [sub-src-make_first] Error 2
> 
> and
> 
>> Module "qt/qtbase" (99b12531013516c060eed60157f8b0be5eafa1e5) The make 
>> execution failed. The CI rejected the staged commits due to the 
>> beforementioned reason. Possible reason could be flakiness in the system, 
>> but could also be a bug in one of the commits.:
>> /opt/yocto-armv7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
>>  -c -include .pch/Qt5Network -pipe -march=armv7-a -mfpu=neon -DLINUX=1 
>> -mfloat-abi=hard 
>> --sysroot=/opt/yocto-armv7/sysroots/armv7ahf-neon-poky-linux-gnueabi -g 
>> -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions 
>> -Wall -W -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Werror 
>> -Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow 
>> -D_REENTRANT -fPIC -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH 
>> -DQT_USE_SYSTEM_PROXIES -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
>> -DQT_BUILD_NETWORK_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII 
>> -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER 
>> -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
>> -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB 
>> -I. -Ikernel -I../../include -I../../include/QtNetwork 
>> -I../../include/QtNetwork/5.11.0 -I../../include/QtNetw
>> ork/5.11.0/QtNetwork -I../../include/QtCore/5.11.0 
>> -I../../include/QtCore/5.11.0/QtCore -I../../include/QtCore -I.moc 
>> -I../../mkspecs/devices/linux-imx7-g++ -o .obj/qnetworkinterface_linux.o 
>> kernel/qnetworkinterface_linux.cpp
>> kernel/qnetworkinterface_linux.cpp: In instantiation of ‘void 
>> {anonymous}::ProcessNetlinkRequest::operator()(int, nlmsghdr*, 
>> char*, size_t, Lambda&&) [with Lambda = getInterfaces(int, 
>> char*)::; size_t = unsigned int]’:
>> kernel/qnetworkinterface_linux.cpp:216:36:   required from ‘void 
>> {anonymous}::processNetlinkRequest(int, nlmsghdr*, char*, size_t, Lambda&&) 
>> [with Lambda = getInterfaces(int, char*)::; 
>> size_t = unsigned int]’
>> kernel/qnetworkinterface_linux.cpp:319:6:   required from here
>> kernel/qnetworkinterface_linux.cpp:161:48: error: comparison between signed 
>> and unsigned integer expressions [-Werror=sign-compare]
>> kernel/qnetworkinterface_linux.cpp: In instantiation of ‘void 
>> {anonymous}::ProcessNetlinkRequest::operator()(int, nlmsghdr*, 
>> char*, size_t, Lambda&&) [with Lambda = getAddresses(int, char*, 
>> QList&)::; size_t = 
>> unsigned int]’:
>> kernel/qnetworkinterface_linux.cpp:216:36:   required from ‘void 
>> {anonymous}::processNetlinkRequest(int, nlmsghdr*, char*, size_t, Lambda&&) 
>> [with Lambda = getAddresses(int, char*, 
>> QList&)::; size_t = 
>> unsigned int]’
>> kernel/qnetworkinterface_linux.cpp:423:6:   required from here
>> kernel/qnetworkinterface_linux.cpp:161:48: error: comparison between signed 
>> and unsigned integer expressions [-Werror=sign-compare]
>> Makefile:26401: recipe for target '.obj/qnetworkinterface_linux.o' failed
>> make[2]: *** [.obj/qnetworkinterface_linux.o] Error 1
>> make[1]: *** [sub-network-make_first] Error 2
>> make: *** [sub-src-make_first] Error 2
> 
> I guess in the first case the system headers changed and in the second case 
> the compiler changed. Do you actually test machine configuration changes 
> against the current state of Qt before you switch them live? I think that 
> should be done and any fixes to Qt for the new configuration should be 
> applied before the configuration goes live.
> 
> br,
> Ulf
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] CI is suffering from problems

2017-12-21 Thread Ulf Hermann

You have probably already noticed this, but here’s an email notifying
you that we’re on it. Our OpenNebula isn’t able to clone any new virtual
machines, complaining that the disk is full even though it isn’t. As
said…we continue investigating.


In addition to that we suddenly get failures when compiling QtCore and 
QtNetwork, even if nothing has changed there:



 Module "qt/qtbase" (9ec8da01004481027df83361b998b24c63ab5a6d) The make 
execution failed. The CI rejected the staged commits due to the beforementioned reason. 
Possible reason could be flakiness in the system, but could also be a bug in one of the 
commits.:
 /home/qt/work/qt/qtbase/src/corelib/global/qfloat16_f16c.c:61: undefined 
reference to `_mm256_cvtps_ph'
 /home/qt/work/qt/qtbase/src/corelib/global/qfloat16_f16c.c:76: undefined 
reference to `_mm256_cvtph_ps'
 Makefile:1152: recipe for target '../../lib/libQt5Core.so.5.11.0' failed
 make[2]: *** [../../lib/libQt5Core.so.5.11.0] Error 1
 make[1]: *** [sub-corelib-make_first] Error 2
 make: *** [sub-src-make_first] Error 2


and


Module "qt/qtbase" (99b12531013516c060eed60157f8b0be5eafa1e5) The make 
execution failed. The CI rejected the staged commits due to the beforementioned reason. 
Possible reason could be flakiness in the system, but could also be a bug in one of the 
commits.:
 
/opt/yocto-armv7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
 -c -include .pch/Qt5Network -pipe -march=armv7-a -mfpu=neon -DLINUX=1 
-mfloat-abi=hard 
--sysroot=/opt/yocto-armv7/sysroots/armv7ahf-neon-poky-linux-gnueabi -g 
-std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions 
-Wall -W -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Werror 
-Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow 
-D_REENTRANT -fPIC -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH 
-DQT_USE_SYSTEM_PROXIES -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_BUILD_NETWORK_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII 
-DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER 
-DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB -I. 
-Ikernel -I../../include -I../../include/QtNetwork 
-I../../include/QtNetwork/5.11.0 -I../../include/QtNetw
 ork/5.11.0/QtNetwork -I../../include/QtCore/5.11.0 
-I../../include/QtCore/5.11.0/QtCore -I../../include/QtCore -I.moc 
-I../../mkspecs/devices/linux-imx7-g++ -o .obj/qnetworkinterface_linux.o 
kernel/qnetworkinterface_linux.cpp
 kernel/qnetworkinterface_linux.cpp: In instantiation of ‘void 
{anonymous}::ProcessNetlinkRequest::operator()(int, nlmsghdr*, char*, size_t, 
Lambda&&) [with Lambda = getInterfaces(int, char*)::; 
size_t = unsigned int]’:
 kernel/qnetworkinterface_linux.cpp:216:36:   required from ‘void 
{anonymous}::processNetlinkRequest(int, nlmsghdr*, char*, size_t, Lambda&&) [with 
Lambda = getInterfaces(int, char*)::; size_t = unsigned 
int]’
 kernel/qnetworkinterface_linux.cpp:319:6:   required from here
 kernel/qnetworkinterface_linux.cpp:161:48: error: comparison between signed 
and unsigned integer expressions [-Werror=sign-compare]
 kernel/qnetworkinterface_linux.cpp: In instantiation of ‘void 
{anonymous}::ProcessNetlinkRequest::operator()(int, nlmsghdr*, char*, size_t, Lambda&&) 
[with Lambda = getAddresses(int, char*, QList&)::; size_t = unsigned int]’:
 kernel/qnetworkinterface_linux.cpp:216:36:   required from ‘void 
{anonymous}::processNetlinkRequest(int, nlmsghdr*, char*, size_t, Lambda&&) [with Lambda = 
getAddresses(int, char*, QList&)::; size_t = unsigned int]’
 kernel/qnetworkinterface_linux.cpp:423:6:   required from here
 kernel/qnetworkinterface_linux.cpp:161:48: error: comparison between signed 
and unsigned integer expressions [-Werror=sign-compare]
 Makefile:26401: recipe for target '.obj/qnetworkinterface_linux.o' failed
 make[2]: *** [.obj/qnetworkinterface_linux.o] Error 1
 make[1]: *** [sub-network-make_first] Error 2
 make: *** [sub-src-make_first] Error 2


I guess in the first case the system headers changed and in the second 
case the compiler changed. Do you actually test machine configuration 
changes against the current state of Qt before you switch them live? I 
think that should be done and any fixes to Qt for the new configuration 
should be applied before the configuration goes live.


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


[Development] CI is suffering from problems

2017-12-21 Thread Tony Sarajärvi
Hi

You have probably already noticed this, but here's an email notifying you that 
we're on it. Our OpenNebula isn't able to clone any new virtual machines, 
complaining that the disk is full even though it isn't. As said...we continue 
investigating.

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


Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework

2017-12-21 Thread Thiago Macieira
On quinta-feira, 21 de dezembro de 2017 04:47:34 CST Konstantin Tokarev wrote:
> > Hi,
> > 
> > Here's a silly one: configuring Qt for building on my Linux rig I was told
> > that I needed Xcode, and how to get it. :)
> > 
> > Long story short, it turns out that the configure script determines
> > whether it's building on Mac by checking if the Carbon framework exists
> > in the designated location. And it turns out that I copied over the
> > entire header dir. structure under /System/Library/Frameworks onto said
> > Linux rig because I use it for cross-platform development.
> > 
> > Apart from the fact that it should probably check for a framework with a
> > more certain future, isn't there a less "rootsy" way of determining
> > whether the script is running on Mac?
> Check uname maybe?

That would tell you the host you're running on, not the target you're 
compiling to.

If your sysroot contains Apple files, it's reasonable to conclude it's an 
Apple system.

-- 
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] About the presence of /System/Library/Frameworks/Carbon.framework

2017-12-21 Thread René J . V . Bertin
On Thursday December 21 2017 13:47:34 Konstantin Tokarev wrote:

> Check uname maybe?

Possibly: just `uname` returns Darwin. That should certainly work for the 
desktop OS, but I have no way of checking what it returns on other Apple OSes 
(and if the Carbon.framework exists there).

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


Re: [Development] Stop delivering 32 bit MinGW binaries from 5.12 ->

2017-12-21 Thread Roland Winklmeier
2017-12-21 11:37 GMT+01:00 Jani Heikkinen :

> With Qt 5.11 it seems we can finally drop MSVC2013 so we could
> "temporarily" add MinGW 64 bit pre-build binaries in our packages in
> addition to 32 bit ones and remove 32 bit MinGW pre-built binaries from
> 5.12 onwards. Making this decision now would complete this discussion
> finally and still give users time to move from 32 bit to 64 bit ones...
>

Hi Jani,

adding MinGW 64 bit sounds great. I would prefer to keep the MinGW 32 bit
ones too, because there are several projects which are plugins to host
applications in 32 bit. So sometimes its not in the scope of the developer
to change his project to 64 bit. Please keep that in mind.
I personally use MSVC2017 together with MSVC2015 32 bit binaries for the
published product. But I regularly use MinGW for daily development. Other
people might prefer MinGW over MSVC for published products though.
So 32 bit software projects are still very common on Windows platforms.

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


Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework

2017-12-21 Thread Konstantin Tokarev


> Hi,
> 
> Here's a silly one: configuring Qt for building on my Linux rig I was told 
> that I needed Xcode, and how to get it. :)
> 
> Long story short, it turns out that the configure script determines whether 
> it's building on Mac by checking if the Carbon framework exists in the 
> designated location. And it turns out that I copied over the entire header 
> dir. structure under /System/Library/Frameworks onto said Linux rig because I 
> use it for cross-platform development.
> 
> Apart from the fact that it should probably check for a framework with a more 
> certain future, isn't there a less "rootsy" way of determining whether the 
> script is running on Mac?

Check uname maybe?

> 
> 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] Stop delivering 32 bit MinGW binaries from 5.12 ->

2017-12-21 Thread Lars Knoll
Hi Jani,

+1 from my side for doing the move to 64bit MinGW in two steps.

Cheers,
Lars

> On 21 Dec 2017, at 11:37, Jani Heikkinen  wrote:
> 
> Hi all,
> 
> There is open suggestion (https://bugreports.qt.io/browse/QTBUG-35288) to 
> start delivering MinGW 64 bit pre-built binaries. This has been requested 
> several times in mails, blog comments etc. We have discussed this earlier, 
> last time with Qt 5.10 where I proposed that we could replace 32 bit MinGW 
> with 64 bit one. But at that time we weren't ready for that. And it seems 32 
> bit MinGW package is still quite widely used, see 
> http://lists.qt-project.org/pipermail/development/2017-December/031674.html .
> 
> With Qt 5.11 it seems we can finally drop MSVC2013 so we could "temporarily" 
> add MinGW 64 bit pre-build binaries in our packages in addition to 32 bit 
> ones and remove 32 bit MinGW pre-built binaries from 5.12 onwards. Making 
> this decision now would complete this discussion finally and still give users 
> time to move from 32 bit to 64 bit ones...
> 
> br,
> Jani
> ___
> 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] Stop delivering 32 bit MinGW binaries from 5.12 ->

2017-12-21 Thread Jani Heikkinen
Hi all,

There is open suggestion (https://bugreports.qt.io/browse/QTBUG-35288) to start 
delivering MinGW 64 bit pre-built binaries. This has been requested several 
times in mails, blog comments etc. We have discussed this earlier, last time 
with Qt 5.10 where I proposed that we could replace 32 bit MinGW with 64 bit 
one. But at that time we weren't ready for that. And it seems 32 bit MinGW 
package is still quite widely used, see 
http://lists.qt-project.org/pipermail/development/2017-December/031674.html .

With Qt 5.11 it seems we can finally drop MSVC2013 so we could "temporarily" 
add MinGW 64 bit pre-build binaries in our packages in addition to 32 bit ones 
and remove 32 bit MinGW pre-built binaries from 5.12 onwards. Making this 
decision now would complete this discussion finally and still give users time 
to move from 32 bit to 64 bit ones...

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


[Development] About the presence of /System/Library/Frameworks/Carbon.framework

2017-12-21 Thread René J . V . Bertin
Hi,

Here's a silly one: configuring Qt for building on my Linux rig I was told that 
I needed Xcode, and how to get it. :)

Long story short, it turns out that the configure script determines whether 
it's building on Mac by checking if the Carbon framework exists in the 
designated location. And it turns out that I copied over the entire header dir. 
structure under /System/Library/Frameworks onto said Linux rig because I use it 
for cross-platform development.

Apart from the fact that it should probably check for a framework with a more 
certain future, isn't there a less "rootsy" way of determining whether the 
script is running on Mac?

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


Re: [Development] Weird issue in CI

2017-12-21 Thread Konstantin Tokarev


> On onsdag 20. desember 2017 17.00.18 CET Konstantin Tokarev wrote:
> 
>> I'm repeatedly getting this error:
>>
>> Failed to provision template 'qtci-linux-Ubuntu-16.04-x86_64-1-b46ac1':
>> Failed repeatedly to launch build/test agent
> 
> This means it never actually did any work because it either didn't get a VM or
> when acquiring one, it didn't manage to communicate with it (we launch a
> program on the VMs = the "agent", which calls home once the machine is up and
> running). I'll improve the error message at least.

Main problem is not error text, but fact that on I restage I get the same error 
again
and again (for same or different VM image)

> 
>> Details:
>> https://testresults.qt.io/coin/integration/qt/qtwebkit/tasks/1513784851
>>
>> No log exist.
> 
> We only show logs when anything happens on a VM (=agent). Since it never got
> that far there is no log, we only have our general logs for all of Coin to
> look at.
> 
> This points to a bug in Coin or the infrastructure below it. Someone who has
> access needs to investigate.
> 
> Cheers,
> Frederik
-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Integrating Common Print Dialog project into Qt

2017-12-21 Thread Rithvik Patibandla


> On 21-Dec-2017, at 2:52 PM, Albert Astals Cid  
> wrote:
> 
> I see a big-ish problem that is that it uses QtQuick so it can't really go 
> into qtbase where the current printing dialog lives, so if this was to be 
> accepted the printing module would need to split off from qtbase (no idea if 
> that is planned or not).
> 

This has been one of our main concerns too. At the time of project planning, we 
were thinking more about QML support because of the missing printing support 
within QML. However, if it is not possible to split the dialog off qtbase, we 
could probably redo the QML part and write the UI using QWidget instead but 
that would be our last option.

> Looking at the code Advanced.qml seems to be collection of items that really 
> don't do anything at all?

The CUPS backend API doesn’t support all of these options yet. So we just put 
up dummy dropdown and we’ll add backend functions to them as soon as the API 
supports it.

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


Re: [Development] Integrating Common Print Dialog project into Qt

2017-12-21 Thread Albert Astals Cid
El dijous, 21 de desembre de 2017, a les 10:14:14 CET, Rithvik Patibandla va 
escriure:
> Hi

Hi

> This summer, OpenPrinting [1] has created a Common Print Dialog project via
> the Google Summer of Code (2017) program to improve the experience of
> printing in Linux systems with a modern UI and backend APIs that will be
> maintained by the OpenPrinting org (the idea can be found here [2]). I am
> one of the students who worked on this project. For the UI, we decided to
> build one using Qt 5. Although, the dialog started as an application to
> ship with individual distributions, we changed course and instead built a
> print dialog API which can be used by application developers to include the
> dialog in their applications.  We wish to integrate this dialog API into Qt
> so that any application built using Qt can use this dialog to include
> support for printing. The code for the dialog can be found here [3]. We
> request the Qt developers to review the code and help us in integrating the
> dialog into Qt. The build instructions are given in the README file and
> screenshots of the dialog will be uploaded very soon.

I see a big-ish problem that is that it uses QtQuick so it can't really go 
into qtbase where the current printing dialog lives, so if this was to be 
accepted the printing module would need to split off from qtbase (no idea if 
that is planned or not).

Looking at the code Advanced.qml seems to be collection of items that really 
don't do anything at all?

Cheers,
  Albert

> 
> Thanks,
> Rithvik
> 
> [1] https://wiki.linuxfoundation.org/openprinting/start
>  [2]
> https://wiki.linuxfoundation.org/gsoc/google-summer-code-2017-openprinting-> 
> projects
>  -projects> [3] https://github.com/rithvikp1998/common-print-dialog
> 


-- 
Albert Astals Cid | albert.astals@kdab.com | 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] Integrating Common Print Dialog project into Qt

2017-12-21 Thread Rithvik Patibandla
Hi

This summer, OpenPrinting [1] has created a Common Print Dialog project via the 
Google Summer of Code (2017) program to improve the experience of printing in 
Linux systems with a modern UI and backend APIs that will be maintained by the 
OpenPrinting org (the idea can be found here [2]). I am one of the students who 
worked on this project. For the UI, we decided to build one using Qt 5. 
Although, the dialog started as an application to ship with individual 
distributions, we changed course and instead built a print dialog API which can 
be used by application developers to include the dialog in their applications.  
We wish to integrate this dialog API into Qt so that any application built 
using Qt can use this dialog to include support for printing. The code for the 
dialog can be found here [3]. We request the Qt developers to review the code 
and help us in integrating the dialog into Qt. The build instructions are given 
in the README file and screenshots of the dialog will be uploaded very soon.

Thanks,
Rithvik

[1] https://wiki.linuxfoundation.org/openprinting/start 

[2] 
https://wiki.linuxfoundation.org/gsoc/google-summer-code-2017-openprinting-projects
 

[3] https://github.com/rithvikp1998/common-print-dialog 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Weird issue in CI

2017-12-21 Thread Frederik Gladhorn
On onsdag 20. desember 2017 17.00.18 CET Konstantin Tokarev wrote:
> I'm repeatedly getting this error:
> 
>  Failed to provision template 'qtci-linux-Ubuntu-16.04-x86_64-1-b46ac1':
>  Failed repeatedly to launch build/test agent

This means it never actually did any work because it either didn't get a VM or 
when acquiring one, it didn't manage to communicate with it (we launch a 
program on the VMs = the "agent", which calls home once the machine is up and 
running). I'll improve the error message at least.

>  Details:
> https://testresults.qt.io/coin/integration/qt/qtwebkit/tasks/1513784851
> 
> No log exist.

We only show logs when anything happens on a VM (=agent). Since it never got 
that far there is no log, we only have our general logs for all of Coin to 
look at.

This points to a bug in Coin or the infrastructure below it. Someone who has 
access needs to investigate.

Cheers,
Frederik

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