From vincenthk007 at gmail.com Mon Jan 1 03:43:09 2018 From: vincenthk007 at gmail.com (Vincent Hui) Date: Mon, 1 Jan 2018 10:43:09 +0800 Subject: [Development] What are new features of Qt3D in Qt 5.11? Message-ID: Hi, Happy new year. In 2018, what are new features of Qt3D in Qt 5.11? Will Rigid body and soft body physics simulation be included? Thanks, Vincent -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Mon Jan 1 10:41:48 2018 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 01 Jan 2018 10:41:48 +0100 Subject: [Development] about the Cocoa/Freetype fontengine References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> <4501587.HH3h8i9JZz@portia.local> Message-ID: <15468151.vy7ANaQElL@patux.local> Nikolaus Waxweiler wrote: >> Right, and where did *that* come from in discussion that's about font >> engine choice by the user? > > We are talking about giving devs the ability to ship Qt apps with > switched font engines, no? Here's what I currently have locally (disregard the hacks for building against Qt 5.8 and the font gamma tweaks, useful though those might be for e.g. visually challenged users): in qcocoaintegration.mm, i.e. the Cocoa QPA: https://github.com/RJVB/osx-integration/blob/qt590/src/qcocoa-qpa/qcocoaintegration.mm#L338 https://github.com/RJVB/osx-integration/blob/qt590/src/qcocoa-qpa/qcocoaintegration.mm#L765 In my osx-integration platform theme plugin which basically does what KDE's plasma-integration plugin does: https://github.com/RJVB/osx-integration/blob/qt590/src/platformtheme/kfontsettingsdatamac.mm#L146 This gives users and developers the possibility to (and in order of priority) - start an application with -platform cocoa:fontengine=[freetype|fontconfig] - use the fontEngine=[freetype|fontconfig|coretext] key in a user-specific settings file (kdeglobals by default). - use an env.variable QT_MAC_FONTENGINE=[freetype|fontconfig|coretext] Evidently this supposes that QtBase has been built with FontConfig support, which in the current state of things requires a few minor patches mostly to override decisions in the build system. Probably still a bit rough around the edges, but I think everything is there to please anyone except maybe strongly principled Qt devs ;) Happy NY! R. From igor.mironchik at gmail.com Mon Jan 1 11:22:18 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 1 Jan 2018 13:22:18 +0300 Subject: [Development] Pushing to gerrit. Message-ID: <160e17d2-13e7-ea22-da5a-56a679dc4764@gmail.com> Hello, I'm new for contributing to Qt. I want to push to gerrit a comment. git push gerrit HEAD:refs/for/5.10 Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Am I missed something during configuring? Or I just don't have rights to push? Maybe something wrong with refs? I just copied push command from http://wiki.qt.io/Qt_Contribution_Guidelines Thank you. From igor.mironchik at gmail.com Mon Jan 1 11:27:32 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 1 Jan 2018 13:27:32 +0300 Subject: [Development] Plugins path Message-ID: <855f933b-6e84-cf34-27b6-6e7a1953ae1a@gmail.com> Hello, I built Qt with -developer-build option. But I can't run any application linked with develop Qt build. Qt can't find plugins. I have to set -platformpluginpath /home/igor/Work/Qt/qt5/qtbase/plugins for Run step in QtCreator. So my question is how do you solve this in your development environment? I don't want to set -platformpluginpath every time on each project. Original qt.conf: [EffectivePaths] Prefix=.. [DevicePaths] Prefix=/home/igor/Work/Qt/qt5/qtbase/bin [Paths] Prefix=/home/igor/Work/Qt/qt5/qtbase/bin HostPrefix=/home/igor/Work/Qt/qt5/qtbase/bin Sysroot= SysrootifyPrefix=false TargetSpec=linux-g++ HostSpec=linux-g++ I tried: [Paths] Prefix=.. Plugins=../plugins Sysroot= SysrootifyPrefix=false TargetSpec=linux-g++ HostSpec=linux-g++ Thank you. From igor.mironchik at gmail.com Mon Jan 1 11:50:36 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 1 Jan 2018 13:50:36 +0300 Subject: [Development] Plugins path In-Reply-To: <855f933b-6e84-cf34-27b6-6e7a1953ae1a@gmail.com> References: <855f933b-6e84-cf34-27b6-6e7a1953ae1a@gmail.com> Message-ID: Hello, Maybe this is because of wrong prefix? I will try to rebuild now... On 01.01.2018 13:27, Igor Mironchik wrote: > Hello, > > I built Qt with -developer-build option. But I can't run any > application linked with develop Qt build. Qt can't find plugins. > > I have to set -platformpluginpath > /home/igor/Work/Qt/qt5/qtbase/plugins for Run step in QtCreator. > > So my question is how do you solve this in your development > environment? I don't want to set -platformpluginpath every time on > each project. > > Original qt.conf: > > [EffectivePaths] > Prefix=.. > [DevicePaths] > Prefix=/home/igor/Work/Qt/qt5/qtbase/bin > [Paths] > Prefix=/home/igor/Work/Qt/qt5/qtbase/bin > HostPrefix=/home/igor/Work/Qt/qt5/qtbase/bin > Sysroot= > SysrootifyPrefix=false > TargetSpec=linux-g++ > HostSpec=linux-g++ > > I tried: > > [Paths] > Prefix=.. > Plugins=../plugins > Sysroot= > SysrootifyPrefix=false > TargetSpec=linux-g++ > HostSpec=linux-g++ > > Thank you. > From aha_1980 at gmx.de Mon Jan 1 12:12:35 2018 From: aha_1980 at gmx.de (aha_1980 at gmx.de) Date: Mon, 1 Jan 2018 11:12:35 +0000 Subject: [Development] Pushing to gerrit. In-Reply-To: <160e17d2-13e7-ea22-da5a-56a679dc4764@gmail.com> References: <160e17d2-13e7-ea22-da5a-56a679dc4764@gmail.com> Message-ID: <72r26v.p1vj50.1hge1d1-qmf@gmx.com> Hi Igor, Am Montag 1. Januar 2018 schrieb Igor Mironchik: > Hello, > > I'm new for contributing to Qt. I want to push to gerrit a comment. > > git push gerrit HEAD:refs/for/5.10 > Permission denied (publickey). > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > Am I missed something during configuring? Or I just don't have rights to > push? Most likely you just don't have added your SSH public key to Gerrit. You can verify by: ssh -p 29418 your-username at codereview.qt-project.org > Maybe something wrong with refs? I don't think so. > I just copied push command from > > http://wiki.qt.io/Qt_Contribution_Guidelines > > Thank you. Happy New Year! Andre > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Von meinem Jolla gesendet From igor.mironchik at gmail.com Mon Jan 1 12:15:10 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 1 Jan 2018 14:15:10 +0300 Subject: [Development] Pushing to gerrit. In-Reply-To: <72r26v.p1vj50.1hge1d1-qmf@gmx.com> References: <160e17d2-13e7-ea22-da5a-56a679dc4764@gmail.com> <72r26v.p1vj50.1hge1d1-qmf@gmx.com> Message-ID: <280fe234-e9b9-e436-87fb-e4f57723a14d@gmail.com> Hi, On 01.01.2018 14:12, aha_1980 at gmx.de wrote: > Hi Igor, > > Am Montag 1. Januar 2018 schrieb Igor Mironchik: >> Hello, >> >> I'm new for contributing to Qt. I want to push to gerrit a comment. >> >> git push gerrit HEAD:refs/for/5.10 >> Permission denied (publickey). >> fatal: Could not read from remote repository. >> >> Please make sure you have the correct access rights >> and the repository exists. >> >> Am I missed something during configuring? Or I just don't have rights to >> push? > Most likely you just don't have added your SSH public key to Gerrit. > > You can verify by: > > ssh -p 29418 your-username at codereview.qt-project.org  ssh -p 29418 igor.mironchik at codereview.qt-project.org Enter passphrase for key '/home/igor/.ssh/id_rsa':   ****    Welcome to Gerrit Code Review    ****   Hi Igor Mironchik, you have successfully connected over SSH.   Unfortunately, interactive shells are disabled.   To clone a hosted Git repository, use:   git clone ssh://igor.mironchik at codereview.qt-project.org:29418/REPOSITORY_NAME.git Connection to codereview.qt-project.org closed. > >> Maybe something wrong with refs? > I don't think so. > >> I just copied push command from >> >> http://wiki.qt.io/Qt_Contribution_Guidelines >> >> Thank you. > Happy New Year! > Andre > >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> From aha_1980 at gmx.de Mon Jan 1 12:27:09 2018 From: aha_1980 at gmx.de (aha_1980 at gmx.de) Date: Mon, 1 Jan 2018 11:27:09 +0000 Subject: [Development] Pushing to gerrit. In-Reply-To: <280fe234-e9b9-e436-87fb-e4f57723a14d@gmail.com> References: <160e17d2-13e7-ea22-da5a-56a679dc4764@gmail.com> <72r26v.p1vj50.1hge1d1-qmf@gmx.com> <280fe234-e9b9-e436-87fb-e4f57723a14d@gmail.com> Message-ID: Am Montag 1. Januar 2018 schrieb Igor Mironchik: > Hi, > > > On 01.01.2018 14:12, aha_1980 at gmx.de wrote: > > Hi Igor, > > > > Am Montag 1. Januar 2018 schrieb Igor Mironchik: > >> Hello, > >> > >> I'm new for contributing to Qt. I want to push to gerrit a comment. > >> > >> git push gerrit HEAD:refs/for/5.10 > >> Permission denied (publickey). > >> fatal: Could not read from remote repository. > >> > >> Please make sure you have the correct access rights > >> and the repository exists. > >> > >> Am I missed something during configuring? Or I just don't have rights to > >> push? > > Most likely you just don't have added your SSH public key to Gerrit. > > > > You can verify by: > > > > ssh -p 29418 your-username at codereview.qt-project.org > > ssh -p 29418 igor.mironchik at codereview.qt-project.org > Enter passphrase for key '/home/igor/.ssh/id_rsa': > > **** Welcome to Gerrit Code Review **** > > Hi Igor Mironchik, you have successfully connected over SSH. > > Unfortunately, interactive shells are disabled. > To clone a hosted Git repository, use: > > git clone > ssh://igor.mironchik at codereview.qt-project.org:29418/REPOSITORY_NAME.git > > Connection to codereview.qt-project.org closed. Looks good. Now verify your git remote (is the port correct there?) Also make sure git uses the right ssh and therefore finds the public key. The problem *is* on your computer. Are you on Windows? > > > >> Maybe something wrong with refs? > > I don't think so. > > > >> I just copied push command from > >> > >> http://wiki.qt.io/Qt_Contribution_Guidelines > >> > >> Thank you. > > Happy New Year! > > Andre > > > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > >> > > -- Von meinem Jolla gesendet From igor.mironchik at gmail.com Mon Jan 1 12:28:20 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 1 Jan 2018 14:28:20 +0300 Subject: [Development] Pushing to gerrit. In-Reply-To: References: <160e17d2-13e7-ea22-da5a-56a679dc4764@gmail.com> <72r26v.p1vj50.1hge1d1-qmf@gmx.com> <280fe234-e9b9-e436-87fb-e4f57723a14d@gmail.com> Message-ID: Hi, On 01.01.2018 14:27, aha_1980 at gmx.de wrote: > > Am Montag 1. Januar 2018 schrieb Igor Mironchik: >> Hi, >> >> >> On 01.01.2018 14:12, aha_1980 at gmx.de wrote: >>> Hi Igor, >>> >>> Am Montag 1. Januar 2018 schrieb Igor Mironchik: >>>> Hello, >>>> >>>> I'm new for contributing to Qt. I want to push to gerrit a comment. >>>> >>>> git push gerrit HEAD:refs/for/5.10 >>>> Permission denied (publickey). >>>> fatal: Could not read from remote repository. >>>> >>>> Please make sure you have the correct access rights >>>> and the repository exists. >>>> >>>> Am I missed something during configuring? Or I just don't have rights to >>>> push? >>> Most likely you just don't have added your SSH public key to Gerrit. >>> >>> You can verify by: >>> >>> ssh -p 29418 your-username at codereview.qt-project.org >> ssh -p 29418 igor.mironchik at codereview.qt-project.org >> Enter passphrase for key '/home/igor/.ssh/id_rsa': >> >> **** Welcome to Gerrit Code Review **** >> >> Hi Igor Mironchik, you have successfully connected over SSH. >> >> Unfortunately, interactive shells are disabled. >> To clone a hosted Git repository, use: >> >> git clone >> ssh://igor.mironchik at codereview.qt-project.org:29418/REPOSITORY_NAME.git >> >> Connection to codereview.qt-project.org closed. > Looks good. Now verify your git remote (is the port correct there?) > > Also make sure git uses the right ssh and therefore finds the public key. > > The problem *is* on your computer. > > Are you on Windows? Think that I found a mistake: possibly this is because of wrong Gerrit user name. I'm on Linux. > >>> >>>> Maybe something wrong with refs? >>> I don't think so. >>> >>>> I just copied push command from >>>> >>>> http://wiki.qt.io/Qt_Contribution_Guidelines >>>> >>>> Thank you. >>> Happy New Year! >>> Andre >>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >> From madigens at gmail.com Mon Jan 1 13:02:33 2018 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Mon, 1 Jan 2018 13:02:33 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: <1842890.OjgxPJRaY0@patux.local> References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> <4501587.HH3h8i9JZz@portia.local> <1842890.OjgxPJRaY0@patux.local> Message-ID: >> Fair enough, depends on your screen and how much you darken. Ideally, >> you match the sRGB gamma curve of roughly 2.2 that in an ideal world, >> your screen matches, too. Ha! > > I recall a difference in opinion between Apple and the rest of the world about > what the correct gamma should be. To me 2.2 always looked too bleak. I read somewhere that 2.2 best matched human perception *shrug*. Gamma correction ideally corrects for your screen gamma curve, which ideally matches the sRGB curve (roughly 2.2). Everyone who plays with calibration knows that this is more wish than reality, so Adobe's internal testing settled on 1.8 according to their Dave Arnold. If you have an old Apple screen that uses 1.8 or something similar, you're already on mark :) > I calibrate my Mac screens btw, not using hardware but with the SuperCal > utility. I use DisplayCal :) > All I can say is that I didn't turn it off and that the font smoothing gamma > value matters. Be more specific. Last I checked, default X11 builds use a gamma correction of 1.0 unless you change the source (only exception, iirc: CFF fonts since 5.9). Also see https://bugreports.qt.io/browse/QTBUG-41590 -- I'd love to close that one, I'd just need to make stem darkening work well for the autohinter and possibly native TrueType hinting... >> No strong hinting preference here, still prefer left for >> the slightly cleaner look should you wonder. > > Hah. Both are Konsole under X11 with Novarese BQ Medium for menus and Ubuntu > Mono for the terminal font. Left is with Infinality+Ultimate (preset #3), right > is stock FT+FC. Are you sure the preset isn't using the autohinter behind the scenes for Ubuntu Mono? The increased x-height at the same point size compared to native hinting is very characteristic :) >> Reworded: you can't reduce the difference between different hinting >> strategies without rewriting the hinting > > And what if you can switch the autohinter on or off per font (or per glyph if > FontConfig allows that kind of control)? I see it's a FreeType property so > technically this should be possible. Yes you can, and it's my favorite mode of operation, but then you're not using or rewriting the native hinting code but using something else :) > BTW, is there a technical reason to expect one cannot change a > fontengine/fontdatabase anymore after the first fonts have been rendered? What do you mean? > Note that Mac OS X at least up to 10.5 allowed setting strong hinting in the system settings Do you mean "font smoothing" (really more of a darkening strength setting)? You can still set it from the command line: `defaults -currentHost write -globalDomain AppleFontSmoothing -int [0123]`. I set it to 1, still darker than I would like, but 0 turns it off and makes fonts appear very gamma corrected ;) From igor.mironchik at gmail.com Mon Jan 1 13:20:06 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 1 Jan 2018 15:20:06 +0300 Subject: [Development] Pushing to gerrit. In-Reply-To: References: <160e17d2-13e7-ea22-da5a-56a679dc4764@gmail.com> <72r26v.p1vj50.1hge1d1-qmf@gmx.com> <280fe234-e9b9-e436-87fb-e4f57723a14d@gmail.com> Message-ID: <433bef77-41d3-fc61-648f-ea564434f5ca@gmail.com> Hi, >> Looks good. Now verify your git remote (is the port correct there?) >> >> Also make sure git uses the right ssh and therefore finds the public >> key. >> >> The problem *is* on your computer. >> >> Are you on Windows? > > Think that I found a mistake: possibly this is because of wrong Gerrit > user name. > > I'm on Linux. I fixed mistake with wrong user name. Now I have following error: igor at gmi:~/Work/Qt/qt5/qtbase$ git push gerrit HEAD:refs/for/5.10 Enter passphrase for key '/home/igor/.ssh/id_rsa': Total 0 (delta 0), reused 0 (delta 0) remote: Processing changes: refs: 1, done To ssh://igor.mironchik at codereview.qt-project.org:29418/qt/qtbase.git  ! [remote rejected] HEAD -> refs/for/5.10 (no new changes) error: failed to push some refs to 'ssh://igor.mironchik at codereview.qt-project.org:29418/qt/qtbase.git' From aha_1980 at gmx.de Mon Jan 1 16:50:23 2018 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Mon, 1 Jan 2018 16:50:23 +0100 Subject: [Development] Pushing to gerrit. In-Reply-To: <433bef77-41d3-fc61-648f-ea564434f5ca@gmail.com> References: <160e17d2-13e7-ea22-da5a-56a679dc4764@gmail.com> <72r26v.p1vj50.1hge1d1-qmf@gmx.com> <280fe234-e9b9-e436-87fb-e4f57723a14d@gmail.com> <433bef77-41d3-fc61-648f-ea564434f5ca@gmail.com> Message-ID: <0bdb448c-2a1a-b8f5-01fd-987ef66d6a63@gmx.de> Hi Igor, Am 01.01.2018 um 13:20 schrieb Igor Mironchik: > Hi, > > >>> Looks good. Now verify your git remote (is the port correct there?) >>> >>> Also make sure git uses the right ssh and therefore finds the public >>> key. >>> >>> The problem *is* on your computer. >>> >>> Are you on Windows? >> >> Think that I found a mistake: possibly this is because of wrong Gerrit >> user name. >> >> I'm on Linux. > > I fixed mistake with wrong user name. Now I have following error: > > igor at gmi:~/Work/Qt/qt5/qtbase$ git push gerrit HEAD:refs/for/5.10 > Enter passphrase for key '/home/igor/.ssh/id_rsa': > Total 0 (delta 0), reused 0 (delta 0) > remote: Processing changes: refs: 1, done > To ssh://igor.mironchik at codereview.qt-project.org:29418/qt/qtbase.git >  ! [remote rejected] HEAD -> refs/for/5.10 (no new changes) > error: failed to push some refs to > 'ssh://igor.mironchik at codereview.qt-project.org:29418/qt/qtbase.git' > Strange. Usually this error appears when you have pushed your changes to Gerrit and then try to re-push them without new changes (as the message already says). Have you already committed your changes? Are you on the correct local branch? What does the commands git log --pretty=oneline | head git branch say? From igor.mironchik at gmail.com Mon Jan 1 17:11:17 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Mon, 1 Jan 2018 19:11:17 +0300 Subject: [Development] Pushing to gerrit. In-Reply-To: <0bdb448c-2a1a-b8f5-01fd-987ef66d6a63@gmx.de> References: <160e17d2-13e7-ea22-da5a-56a679dc4764@gmail.com> <72r26v.p1vj50.1hge1d1-qmf@gmx.com> <280fe234-e9b9-e436-87fb-e4f57723a14d@gmail.com> <433bef77-41d3-fc61-648f-ea564434f5ca@gmail.com> <0bdb448c-2a1a-b8f5-01fd-987ef66d6a63@gmx.de> Message-ID: Hi, On 01.01.2018 18:50, André Hartmann wrote: > Hi Igor, > > Am 01.01.2018 um 13:20 schrieb Igor Mironchik: >> Hi, >> >> >>>> Looks good. Now verify your git remote (is the port correct there?) >>>> >>>> Also make sure git uses the right ssh and therefore finds the >>>> public key. >>>> >>>> The problem *is* on your computer. >>>> >>>> Are you on Windows? >>> >>> Think that I found a mistake: possibly this is because of wrong >>> Gerrit user name. >>> >>> I'm on Linux. >> >> I fixed mistake with wrong user name. Now I have following error: >> >> igor at gmi:~/Work/Qt/qt5/qtbase$ git push gerrit HEAD:refs/for/5.10 >> Enter passphrase for key '/home/igor/.ssh/id_rsa': >> Total 0 (delta 0), reused 0 (delta 0) >> remote: Processing changes: refs: 1, done >> To ssh://igor.mironchik at codereview.qt-project.org:29418/qt/qtbase.git >>   ! [remote rejected] HEAD -> refs/for/5.10 (no new changes) >> error: failed to push some refs to >> 'ssh://igor.mironchik at codereview.qt-project.org:29418/qt/qtbase.git' >> > > Strange. Usually this error appears when you have pushed your changes > to Gerrit and then try to re-push them without new changes (as the > message already says). > > Have you already committed your changes? Are you on the correct local > branch? > > What does the commands > >  git log --pretty=oneline | head > >  git branch > > say? I did a commit on local branch, but after it I had to re-init repository. And this did something with the head. Thank you for the suggestion I just checked out my local branch again and push completed successfully. Thank you guys. From aha_1980 at gmx.de Mon Jan 1 17:19:13 2018 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Mon, 1 Jan 2018 17:19:13 +0100 Subject: [Development] Pushing to gerrit. In-Reply-To: References: <160e17d2-13e7-ea22-da5a-56a679dc4764@gmail.com> <72r26v.p1vj50.1hge1d1-qmf@gmx.com> <280fe234-e9b9-e436-87fb-e4f57723a14d@gmail.com> <433bef77-41d3-fc61-648f-ea564434f5ca@gmail.com> <0bdb448c-2a1a-b8f5-01fd-987ef66d6a63@gmx.de> Message-ID: <6c448b4a-1882-9562-3924-13d69299105a@gmx.de> Am 01.01.2018 um 17:11 schrieb Igor Mironchik: > Hi, > > > On 01.01.2018 18:50, André Hartmann wrote: >> Hi Igor, >> >> Am 01.01.2018 um 13:20 schrieb Igor Mironchik: >>> Hi, >>> >>> >>>>> Looks good. Now verify your git remote (is the port correct there?) >>>>> >>>>> Also make sure git uses the right ssh and therefore finds the >>>>> public key. >>>>> >>>>> The problem *is* on your computer. >>>>> >>>>> Are you on Windows? >>>> >>>> Think that I found a mistake: possibly this is because of wrong >>>> Gerrit user name. >>>> >>>> I'm on Linux. >>> >>> I fixed mistake with wrong user name. Now I have following error: >>> >>> igor at gmi:~/Work/Qt/qt5/qtbase$ git push gerrit HEAD:refs/for/5.10 >>> Enter passphrase for key '/home/igor/.ssh/id_rsa': >>> Total 0 (delta 0), reused 0 (delta 0) >>> remote: Processing changes: refs: 1, done >>> To ssh://igor.mironchik at codereview.qt-project.org:29418/qt/qtbase.git >>>   ! [remote rejected] HEAD -> refs/for/5.10 (no new changes) >>> error: failed to push some refs to >>> 'ssh://igor.mironchik at codereview.qt-project.org:29418/qt/qtbase.git' >>> >> >> Strange. Usually this error appears when you have pushed your changes >> to Gerrit and then try to re-push them without new changes (as the >> message already says). >> >> Have you already committed your changes? Are you on the correct local >> branch? >> >> What does the commands >> >>  git log --pretty=oneline | head >> >>  git branch >> >> say? > > I did a commit on local branch, but after it I had to re-init > repository. And this did something with the head. init-repository is effective git submodule update. And yes, that checks out the SHA1 of each submodule as it is specified in qt5.git. > Thank you for the suggestion I just checked out my local branch > again and push completed successfully > Thank you guys. You're welcome. And thanks for your fix. Andre From thiago.macieira at intel.com Mon Jan 1 21:08:44 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 01 Jan 2018 18:08:44 -0200 Subject: [Development] Plugins path In-Reply-To: <855f933b-6e84-cf34-27b6-6e7a1953ae1a@gmail.com> References: <855f933b-6e84-cf34-27b6-6e7a1953ae1a@gmail.com> Message-ID: <2094699.s26dtbuNzx@tjmaciei-mobl1> On Monday, 1 January 2018 08:27:32 -02 Igor Mironchik wrote: > Hello, > > I built Qt with -developer-build option. But I can't run any application > linked with develop Qt build. Qt can't find plugins. Hello Igor What was your configure line? Can you run the following and paste the output: which qmake qmake -query and please run libQt5Core.so.5 too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Mon Jan 1 21:36:06 2018 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 01 Jan 2018 21:36:06 +0100 Subject: [Development] about the Cocoa/Freetype fontengine References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> <4501587.HH3h8i9JZz@portia.local> <1842890.OjgxPJRaY0@patux.local> Message-ID: <10316036.y2g1Br6u7r@patux.local> Nikolaus Waxweiler wrote: >> All I can say is that I didn't turn it off and that the font smoothing gamma >> value matters. > > Be more specific. You asked if gamma correction is enabled in my Qt builds, the only way I can answer that without additional information is the way I did. A priori it's enabled if it should be by default, not if it should be off by default. > Last I checked, default X11 builds use a gamma > correction of 1.0 unless you change the source (only exception, iirc: The only change I made was the default value of the font smoothing gamma. > Also see https://bugreports.qt.io/browse/QTBUG-41590 -- I'd love to > close that one, I'd just need to make stem darkening work well for the Funny, I never had complaints about too-thin fonts in Qt5 compared to Qt4. Certain medium/semibold fonts are indeed thinner (sleeker, not paler), but they're too heavy in Qt4. > Are you sure the preset isn't using the autohinter behind the scenes > for Ubuntu Mono? No, I'm not sure and I don't know how to verify that either. But comparing specific glyphs with the same font in ftview I'd say that no, autohinting isn't on. There are comments in the tweaked fontconfig files, but they assume a better familiarity with the subject than I have. > The increased x-height at the same point size > compared to native hinting is very characteristic :) The at symbol doesn't look like it does when autohinted, in particular. >> BTW, is there a technical reason to expect one cannot change a >> fontengine/fontdatabase anymore after the first fonts have been rendered? > > What do you mean? Basically, can you switch the fontengine and fontdatabase freely at runtime, or can this only be done as long as the application hasn't started using fonts? R. From igor.mironchik at gmail.com Tue Jan 2 08:13:20 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Tue, 2 Jan 2018 10:13:20 +0300 Subject: [Development] Plugins path In-Reply-To: <2094699.s26dtbuNzx@tjmaciei-mobl1> References: <855f933b-6e84-cf34-27b6-6e7a1953ae1a@gmail.com> <2094699.s26dtbuNzx@tjmaciei-mobl1> Message-ID: <1dd2b698-4155-4445-d50d-228dfa28ac7a@gmail.com> Hello, I found the problem. I configured Qt with wrong -prefix: $PWD/qtbase/bin so Qt should be installed for proper work. After make install all work. But this is not convenient. I did ./configure again with correct -prefix: $PWD/qtbase with -redo option. But in this case -prefix uses old value from config.opt. So I have to rebuild again. I deleted config.opt file. Launched ./configure... Now qmake -query produces: QT_SYSROOT: QT_INSTALL_PREFIX:/home/igor/Work/Qt/qt5/qtbase QT_INSTALL_ARCHDATA:/home/igor/Work/Qt/qt5/qtbase QT_INSTALL_DATA:/home/igor/Work/Qt/qt5/qtbase QT_INSTALL_DOCS:/home/igor/Work/Qt/qt5/qtbase/doc QT_INSTALL_HEADERS:/home/igor/Work/Qt/qt5/qtbase/include QT_INSTALL_LIBS:/home/igor/Work/Qt/qt5/qtbase/lib QT_INSTALL_LIBEXECS:/home/igor/Work/Qt/qt5/qtbase/libexec QT_INSTALL_BINS:/home/igor/Work/Qt/qt5/qtbase/bin QT_INSTALL_TESTS:/home/igor/Work/Qt/qt5/qtbase/tests QT_INSTALL_PLUGINS:/home/igor/Work/Qt/qt5/qtbase/plugins QT_INSTALL_IMPORTS:/home/igor/Work/Qt/qt5/qtbase/imports QT_INSTALL_QML:/home/igor/Work/Qt/qt5/qtbase/qml QT_INSTALL_TRANSLATIONS:/home/igor/Work/Qt/qt5/qtbase/translations QT_INSTALL_CONFIGURATION:/home/igor/Work/Qt/qt5/qtbase QT_INSTALL_EXAMPLES:/home/igor/Work/Qt/qt5/qtbase/examples QT_INSTALL_DEMOS:/home/igor/Work/Qt/qt5/qtbase/examples QT_HOST_PREFIX:/home/igor/Work/Qt/qt5/qtbase QT_HOST_DATA:/home/igor/Work/Qt/qt5/qtbase QT_HOST_BINS:/home/igor/Work/Qt/qt5/qtbase/bin QT_HOST_LIBS:/home/igor/Work/Qt/qt5/qtbase/lib QMAKE_SPEC:linux-g++ QMAKE_XSPEC:linux-g++ QMAKE_VERSION:3.1 QT_VERSION:5.10.0 That seems good. Waiting for build, guess that all will be ok. Thank you. On 01.01.2018 23:08, Thiago Macieira wrote: > On Monday, 1 January 2018 08:27:32 -02 Igor Mironchik wrote: >> Hello, >> >> I built Qt with -developer-build option. But I can't run any application >> linked with develop Qt build. Qt can't find plugins. > Hello Igor > > What was your configure line? Can you run the following and paste the output: > > which qmake > qmake -query > > and please run libQt5Core.so.5 too. > From andre.hartmann at iseg-hv.de Tue Jan 2 09:30:55 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Tue, 2 Jan 2018 09:30:55 +0100 Subject: [Development] Stop delivering 32 bit MinGW binaries from 5.12 -> In-Reply-To: References: Message-ID: <765dea96-2615-8af9-f3e6-f926b87e9994@iseg-hv.de> Hi Jani and Roland, First: Happy New Year to all! Am 21.12.2017 um 11:59 schrieb 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 fully acknowledge this! > 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. And not to forget, 32 bit Windows programs run without problems on 64 bit Windows systems; the opposite is not true. Best regards, André From sean.harmer at kdab.com Tue Jan 2 10:24:16 2018 From: sean.harmer at kdab.com (Sean Harmer) Date: Tue, 2 Jan 2018 09:24:16 +0000 Subject: [Development] What are new features of Qt3D in Qt 5.11? In-Reply-To: References: Message-ID: Hi, On 01/01/2018 02:43, Vincent Hui wrote: > Hi, > > Happy new year. In 2018, what are new features of Qt3D in Qt 5.11? Will > Rigid body and soft body physics simulation be included? It will mainly be performance and stabilisation in Qt 3D for 5.11. The physics integration is not ready yet. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From thiago.macieira at intel.com Tue Jan 2 11:37:07 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 Jan 2018 08:37:07 -0200 Subject: [Development] Plugins path In-Reply-To: <1dd2b698-4155-4445-d50d-228dfa28ac7a@gmail.com> References: <855f933b-6e84-cf34-27b6-6e7a1953ae1a@gmail.com> <2094699.s26dtbuNzx@tjmaciei-mobl1> <1dd2b698-4155-4445-d50d-228dfa28ac7a@gmail.com> Message-ID: <5410645.jFm8fCqylU@tjmaciei-mobl1> On Tuesday, 2 January 2018 05:13:20 -02 Igor Mironchik wrote: > So I have to rebuild again. I deleted config.opt file. Launched > ./configure... Delete a few more files besides config.opt. In fact, all of them that were created after you typed configure (including all created by make). Git clean helps. rm -rf a shadow build is better. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jan 2 11:39:08 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 Jan 2018 08:39:08 -0200 Subject: [Development] Stop delivering 32 bit MinGW binaries from 5.12 -> In-Reply-To: <765dea96-2615-8af9-f3e6-f926b87e9994@iseg-hv.de> References: <765dea96-2615-8af9-f3e6-f926b87e9994@iseg-hv.de> Message-ID: <1592674.6G4ZWvdJNy@tjmaciei-mobl1> On Tuesday, 2 January 2018 06:30:55 -02 André Hartmann wrote: > > 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. > > And not to forget, 32 bit Windows programs run without problems on 64 > bit Windows systems; the opposite is not true. True, but how many people install Windows 7+ 32-bit these days? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From vincenthk007 at gmail.com Tue Jan 2 11:46:49 2018 From: vincenthk007 at gmail.com (Vincent Hui) Date: Tue, 2 Jan 2018 18:46:49 +0800 Subject: [Development] What are new features of Qt3D in Qt 5.11? In-Reply-To: References: Message-ID: Hi Sean, Thank you for your reply. Is it possible to offer the physics integration to Qt users as a technology preview in Qt 5.11 before it is ready? I watched your video clip "Qt 3D Rigid Body Physics" 11 months ago. Thanks, Vincent On 2 January 2018 at 17:24, Sean Harmer wrote: > Hi, > > On 01/01/2018 02:43, Vincent Hui wrote: > >> Hi, >> >> Happy new year. In 2018, what are new features of Qt3D in Qt 5.11? Will >> Rigid body and soft body physics simulation be included? >> > > It will mainly be performance and stabilisation in Qt 3D for 5.11. The > physics integration is not ready yet. > > Cheers, > > Sean > > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > KDAB (UK) Ltd, a KDAB Group company > Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 > Mobile: +44 (0)7545 140604 > KDAB - Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.mironchik at gmail.com Tue Jan 2 12:29:42 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Tue, 2 Jan 2018 14:29:42 +0300 Subject: [Development] Plugins path In-Reply-To: <5410645.jFm8fCqylU@tjmaciei-mobl1> References: <855f933b-6e84-cf34-27b6-6e7a1953ae1a@gmail.com> <2094699.s26dtbuNzx@tjmaciei-mobl1> <1dd2b698-4155-4445-d50d-228dfa28ac7a@gmail.com> <5410645.jFm8fCqylU@tjmaciei-mobl1> Message-ID: Hi, On 02.01.2018 13:37, Thiago Macieira wrote: > On Tuesday, 2 January 2018 05:13:20 -02 Igor Mironchik wrote: >> So I have to rebuild again. I deleted config.opt file. Launched >> ./configure... > Delete a few more files besides config.opt. In fact, all of them that were > created after you typed configure (including all created by make). > > Git clean helps. rm -rf a shadow build is better. In my case deletion of the config.opt helped enough. Now all rocks. Thank you. From igor.mironchik at gmail.com Tue Jan 2 12:34:45 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Tue, 2 Jan 2018 14:34:45 +0300 Subject: [Development] Pushing with the same change id to the another branch. Message-ID: <5c6e0dbb-647d-8719-7a6d-81e842951e77@gmail.com> Hello, I pushed a change for code review into the 5.10 branch. But this patch can't be merged into 5.10 branch since this is behavior change. Now I want to push the same change (commit) into dev branch. So my question is it possible to do just: git push gerrit HEAD:refs/for/dev Change id will be the same in 5.10 branch review and in dev branch... Is it ok? Will it work? Thank you. From annulen at yandex.ru Tue Jan 2 12:39:32 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 02 Jan 2018 14:39:32 +0300 Subject: [Development] Pushing with the same change id to the another branch. In-Reply-To: <5c6e0dbb-647d-8719-7a6d-81e842951e77@gmail.com> References: <5c6e0dbb-647d-8719-7a6d-81e842951e77@gmail.com> Message-ID: <1354631514893172@web24g.yandex.ru> > Hello, > > I pushed a change for code review into the 5.10 branch. But this patch > can't be merged into 5.10 branch since this is behavior change. Now I > want to push the same change (commit) into dev branch. So my question is > it possible to do just: > > git push gerrit HEAD:refs/for/dev > > Change id will be the same in 5.10 branch review and in dev branch... Is > it ok? Will it work? No, you should go to #qt-labs and ask ossi or fregl to move your change to a different branch > > Thank you. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Tue Jan 2 13:12:10 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 Jan 2018 10:12:10 -0200 Subject: [Development] Pushing with the same change id to the another branch. In-Reply-To: <5c6e0dbb-647d-8719-7a6d-81e842951e77@gmail.com> References: <5c6e0dbb-647d-8719-7a6d-81e842951e77@gmail.com> Message-ID: <3098635.heBtnCfZL6@tjmaciei-mobl1> On Tuesday, 2 January 2018 09:34:45 -02 Igor Mironchik wrote: > Hello, > > I pushed a change for code review into the 5.10 branch. But this patch > can't be merged into 5.10 branch since this is behavior change. Now I > want to push the same change (commit) into dev branch. So my question is > it possible to do just: > > git push gerrit HEAD:refs/for/dev > > Change id will be the same in 5.10 branch review and in dev branch... Is > it ok? Will it work? You can reuse the same ID in different branches and in different repositories. That's not a problem. I often use the same ID in multiple repositories when I am making the same change everywhere (usually a search-and-replace). But that said, you shouldn't re-push the same change to a different branch, you should ask that the change be moved to a different branch, so we can keep the history of comments in a single place. See Konstantin's email. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From frederik.gladhorn at qt.io Tue Jan 2 14:46:17 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 02 Jan 2018 14:46:17 +0100 Subject: [Development] Reporting errors for powershell scripts executed by Coin In-Reply-To: References: <296601513881425@web10o.yandex.ru> Message-ID: <10928607.1AFrzTNvt3@frederik-thinkcentre-m93p> On fredag 22. desember 2017 09.17.47 CET Tony Sarajärvi wrote: > Hi > > We ignore the results of PS1 scripts because A) We have bad scripts that try > to remove folders that don't exists anymore (should be cleaned) and B) as > your example said, if we enabled enforcing of them now, things would break > apart (fix needed as well 😝) I would consider this a major bug. We never intended to ignore errors in the PS scripts and shouldn't. https://bugreports.qt.io/browse/QTQAINFRA-1178 considered this a P0 and should be re-opened if we have this happening again. Cheers, Frederik > -T > > -----Original Message----- > From: Development > [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf > Of Konstantin Tokarev Sent: torstai 21. joulukuuta 2017 20.37 > To: development at qt-project.org > Subject: [Development] Reporting errors for powershell scripts executed by > Coin > 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 at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From frederik.gladhorn at qt.io Tue Jan 2 14:50:17 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 02 Jan 2018 14:50:17 +0100 Subject: [Development] Weird issue in CI In-Reply-To: <682481513849580@web50o.yandex.ru> References: <266961513785618@web6o.yandex.ru> <21044012.QVaT3I9ram@frederik-thinkcentre-m93p> <682481513849580@web50o.yandex.ru> Message-ID: <17852405.UMXPhLCVUD@frederik-thinkcentre-m93p> On torsdag 21. desember 2017 10.46.20 CET Konstantin Tokarev wrote: > > 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) Indeed, let me quote myself: > > This points to a bug in Coin or the infrastructure below it. Someone who > > has access needs to investigate. There was nothing you could do, it was due to a filesystem claiming it had space while it didn't. If you get the same message repeatedly, it points at underlying problems and restaging is probably pointless. Cheers, Frederik > > >> 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 From kevron.m.rees at intel.com Tue Jan 2 17:30:07 2018 From: kevron.m.rees at intel.com (Rees, Kevron) Date: Tue, 2 Jan 2018 08:30:07 -0800 Subject: [Development] What are new features of Qt3D in Qt 5.11? In-Reply-To: References: Message-ID: What about a fix for multi-viewport picking (QTBUG-59567)? On Tue, Jan 2, 2018 at 2:46 AM, Vincent Hui wrote: > Hi Sean, > > Thank you for your reply. > > Is it possible to offer the physics integration to Qt users as a technology > preview in Qt 5.11 before it is ready? I watched your video clip "Qt 3D > Rigid Body Physics" 11 months ago. > > Thanks, > Vincent > > On 2 January 2018 at 17:24, Sean Harmer wrote: >> >> Hi, >> >> On 01/01/2018 02:43, Vincent Hui wrote: >>> >>> Hi, >>> >>> Happy new year. In 2018, what are new features of Qt3D in Qt 5.11? Will >>> Rigid body and soft body physics simulation be included? >> >> >> It will mainly be performance and stabilisation in Qt 3D for 5.11. The >> physics integration is not ready yet. >> >> Cheers, >> >> Sean >> >> -- >> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK >> KDAB (UK) Ltd, a KDAB Group company >> Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 >> Mobile: +44 (0)7545 140604 >> KDAB - Qt Experts >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From jani.heikkinen at qt.io Wed Jan 3 13:00:37 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 3 Jan 2018 12:00:37 +0000 Subject: [Development] Branching '5.9.4' from '5.9' done In-Reply-To: References: Message-ID: Hi! Branching from '5.9' to '5.9.4' is now ready. So all changes targeted to Qt 5.9.4 release must be done in '5.9.4' and '5.9' is for Qt 5.9.5 from now on br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Friday, December 22, 2017 4:26 PM To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] Branching '5.9.4' from '5.9' started Hi all, We have now soft branched '5.9.4' from '5.9' so please start using '5.9.4' for new changes targeting Qt 5.9.4 release. Target is to do final downmerge from '5.9' -> '5.9.4' and finalize branching at the beginning of January 2018 so there should be enough time to finalize ongoing ones in '5.9'. Target is to release Qt 5.9.4 ~ mid January. br, Jani Heikkinen Release Manager _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From tpham3783 at gmail.com Wed Jan 3 17:26:11 2018 From: tpham3783 at gmail.com (Toan Pham) Date: Wed, 3 Jan 2018 11:26:11 -0500 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: <2126029.WM82Itbiqh@tjmaciei-mobl1> References: <1579689.60vB0ZmokD@tjmaciei-mobl1> <2707441513945812@web4g.yandex.ru> <2126029.WM82Itbiqh@tjmaciei-mobl1> Message-ID: Thiago, I over came the memory limitation by forcing ninja to run in single thread (pass -j 1 to ninja). However, at linking stage using a 32bit linker, the linker failed because it could not find references to avx2 in libvpx, a third-party library that I hacked to get AVX2 disabled. Since you've been recommending that I should use 64bit linker, this error is completely unrelated to the memory address limit of a 32bit linker. While the 32bit linker was doing its job linking libQt5WebEngine.so, its maximum memory usage (RSS) was 1.8GB, not anywhere close to the maximum addressable limit of 32bit executables. g++ -Wl,--no-undefined -Wl,--version-script,QtWebEngineCore.version -Wl,--gc-sections -Wl,-O1 -Wl,-z,now -Wl,-z,defs -Wl,-O1 -Wl,--enable-new-dtags -Wl,-z,origin -Wl,-rpath,\$ORIGIN -shared -Wl,-soname,libQt5WebEn gineCore.so.5 -o libQt5WebEngineCore.so.5.10.0 -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtdeclarative/lib -lQt5Quick -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtb ase/lib -lQt5Gui -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtdeclarative/lib -lQt5Qml -lQt5Network -lQt5Core -lpthread -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtba se/lib -lQt5Gui -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Core -lpthread -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebchannel/lib -lQt5WebChannel - L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtdeclarative/lib -lQt5Qml -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Network -lQt5Core -lpthread -lQt5Qml -L /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Network -lQt5Core -lpthread -lQt5Network -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Core -lpth read -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtlocation/lib -lQt5Positioning -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Core -lpthread -lQt5Core -lp thread -lpthread @/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/Qt5WebEngineCore.rsp -Wl,--start-group /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0 /qtwebengine/src/core/release/obj/base/libbase.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/error_page/common/libcommon.a /TOOLCHAIN/loop/target/nic ebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/keyed_service/content/libkeyed_service_content.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/co re/release/obj/components/visitedlink/browser/libbrowser.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/visitedlink/renderer/librenderer.a /TOOLCHAIN/ loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/web_cache/browser/libbrowser.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/ release/obj/components/web_cache/renderer/librenderer.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/net/libnet_with_v8.a /TOOLCHAIN/loop/target/nicebox/sandbox/ qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/skia/libskia.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/accessibility/libaccessibility.a /TOOLCH AIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/cdm/renderer/librenderer.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/ release/obj/base/libbase_static.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/base/third_party/dynamic_annotations/libdynamic_annotations.a /TOOLCHAIN/loop/targ et/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/modp_b64/libmodp_b64.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/base /third_party/libevent/libbundled_libevent.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/base/third_party/symbolize/libsymbolize.a /TOOLCHAIN/loop/target/nicebox /sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/base/third_party/xdg_mime/libxdg_mime.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/base/thir d_party/xdg_user_dirs/libxdg_user_dirs.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/base/libbase_i18n.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-sr c-5.10.0/qtwebengine/src/core/release/obj/third_party/ced/libced.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/icu/libbundled_icui18n.a /TOOLCHAIN/l oop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/icu/libbundled_icuuc.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/ obj/components/offline_pages/core/libswitches.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/version_info/libversion_info.a /TOOLCHAIN/loop/target/nic ebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/url_formatter/liburl_formatter.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/n et/libnet.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/net/libnet_quic_proto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/ core/release/obj/third_party/protobuf/libprotobuf_lite.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/crypto/libcrcrypto.a /TOOLCHAIN/loop/target/nicebox/sandbox /qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/boringssl/libboringssl.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/url/liburl.a /TOOLCH AIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/sdch/libsdch.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party /zlib/libchrome_zlib.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/zlib/libzlib_x86_simd.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src- 5.10.0/qtwebengine/src/core/release/obj/third_party/brotli/libdec.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/brotli/libcommon.a /TOOLCHAIN/loop/t arget/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gfx/libgfx.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gfx/libcolor_spac e.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gfx/libgfx_switches.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/re lease/obj/third_party/libjpeg_turbo/libjpeg.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libjpeg_turbo/libsimd.a /TOOLCHAIN/loop/target/nicebox/san dbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libjpeg_turbo/libsimd_asm.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/l ibwebp/libwebp_dec.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libwebp/libwebp_dsp.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10 .0/qtwebengine/src/core/release/obj/third_party/libwebp/libwebp_dsp_sse2.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libwebp/libwebp_dsp_sse41.a / TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libwebp/libwebp_utils.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/c ore/release/obj/third_party/libwebp/libwebp_demux.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libwebp/libwebp_enc.a /TOOLCHAIN/loop/target/nicebox /sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libwebp/libwebp_mux.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/sfn tly/libsfntly.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gfx/x/libgfx_x11.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/sr c/core/release/obj/ui/gfx/libgeometry_skia.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gfx/geometry/libgeometry.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt -everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libdrm/libdrm.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gfx/animation/libanimation.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gfx/codec/libcodec.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release /obj/ui/gfx/range/librange.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/cc/paint/libcc_paint.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/ qtwebengine/src/core/release/obj/cc/base/libcc_base.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/cc/debug/libcc_debug.a /TOOLCHAIN/loop/target/nicebox/sandbox/ qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/harfbuzz-ng/libharfbuzz-ng-ft.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/ha rfbuzz-ng/libharfbuzz-ng-without-freetype.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/base/libui_base.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywher e-src-5.10.0/qtwebengine/src/core/release/obj/ui/base/libui_data_pack.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/events/libevents_base.a /TOOLCHAIN/loop/t arget/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/events/libdom_keycode_converter.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj /ui/events/platform/libplatform.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/events/keycodes/libkeycodes_x11.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-eve rywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/base/x/libui_base_x.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/events/libevents.a /TOOLCHAIN/loop/t arget/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/events/libgesture_detection.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/ display/libdisplay.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/display/types/libdisplay_types.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. 10.0/qtwebengine/src/core/release/obj/third_party/re2/libbundled_re2.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/display/util/libdisplay_util.a /TOOLCHAIN/ loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/events/devices/libdevices.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj /ui/events/devices/x11/libevents_devices_x11.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/events/x/libevents_x.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-e verywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/events/platform/x11/libx11_events_platform.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/key ed_service/core/libkeyed_service_core.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/pref_registry/libpref_registry.a /TOOLCHAIN/loop/target/nicebox/s andbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/prefs/libprefs.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/user_prefs/l ibuser_prefs.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/mojo/public/cpp/bindings/libbindings.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10. 0/qtwebengine/src/core/release/obj/mojo/public/cpp/system/libmojo_public_system_cpp.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/mojo/public/c/system/libmojo_p ublic_system.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ipc/libipc.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/rel ease/obj/ipc/libipc_mojom.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/accessibility/libax_gen.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. 10.0/qtwebengine/src/core/release/obj/cc/libcc.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/viz/common/libviz_common.a /TOOLCHAIN/loop/target/nicebo x/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/gpu/command_buffer/common/libgles2_utils.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/gpu/c ommand_buffer/service/libservice_sources.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/gpu/command_buffer/service/libdisk_cache_proto.a /TOOLCHAIN/loop/target/n icebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gl/libgl_wrapper.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gl/init/libgl_init .a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/angle/libangle_gpu_info_util.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebe ngine/src/core/release/obj/third_party/angle/libangle_common.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/angle/libangle_image_util.a /TOOLCHAIN/lo op/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/angle/libtranslator.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/ob j/third_party/angle/libpreprocessor.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/smhasher/libcityhash.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-e verywhere-src-5.10.0/qtwebengine/src/core/release/obj/gpu/ipc/libcommand_buffer_sources.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gfx/ipc/libgfx_ipc.a /T OOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gfx/ipc/geometry/libgfx_ipc_geometry.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/ src/core/release/obj/url/ipc/liburl_ipc.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/gpu/ipc/service/libipc_service_sources.a /TOOLCHAIN/loop/target/nicebox/sa ndbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/gpu/command_buffer/client/libgles2_implementation.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ gpu/ipc/libgl_in_process_context.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/mojo/common/libmojo_common_lib.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everyw here-src-5.10.0/qtwebengine/src/core/release/obj/media/libmedia.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/media/libshared_memory_support.a /TOOLCHAIN/loop/t arget/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/media/base/libbase.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/lib yuv/libyuv_internal.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/ffmpeg/libffmpeg_internal.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-s rc-5.10.0/qtwebengine/src/core/release/obj/third_party/opus/libbundled_opus.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/ffmpeg/libffmpeg_yasm.a /T OOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libvpx/libbundled_libvpx.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src /core/release/obj/third_party/libvpx/libvpx_yasm.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/media/cdm/libcdm_paths.a /TOOLCHAIN/loop/target/nicebox/sandbox/q t-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libwebm/libwebm.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/services/service_manager/publ ic/interfaces/libservice_manager_mojom.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/services/service_manager/public/interfaces/libservice_manager_mojom_constan ts.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/services/service_manager/public/cpp/libservice_manager_cpp_types.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-ev erywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gfx/ipc/color/libgfx_ipc_color.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/gfx/ipc/skia/libgfx_ipc_ skia.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/media/capture/libcapture_base.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/s rc/core/release/obj/ui/base/ime/libui_base_ime.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/device/bluetooth/libbluetooth.a /TOOLCHAIN/loop/target/nicebox/sand box/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/device_event_log/libdevice_event_log.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/dbus /libdbus.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/password_manager/core/common/libcommon.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere- src-5.10.0/qtwebengine/src/core/release/obj/components/autofill/core/common/libcommon.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/variations/libvar iations.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/variations/proto/libproto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtw ebengine/src/core/release/obj/components/crash/core/common/libcrash_keys.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/mt19937ar/libmt19937ar.a /TOO LCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/zlib/google/libcompression_utils.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengi ne/src/core/release/obj/sql/libsql.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/sqlite/libchromium_sqlite3.a /TOOLCHAIN/loop/target/nicebox/sandbox /qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/cc/ipc/libcc_ipc.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/cc/surfaces/libcc_surfaces.a /TOOLCHAI N/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/aura/libaura.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/composi tor/libcompositor.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/cc/animation/libcc_animation.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/q twebengine/src/core/release/obj/components/viz/host/libhost.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/viz/service/libservice.a /TOOLCHAIN/loop/ta rget/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/discardable_memory/client/libdiscardable_memory_client.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qt webengine/src/core/release/obj/components/discardable_memory/common/libdiscardable_memory_common.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/services/service_ manager/public/cpp/libservice_manager_cpp.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/platform_window/mojo/libmojo_ime_lib.a /TOOLCHAIN/loop/target/nicebox /sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/platform_window/stub/libstub_window.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/surfa ce/libsurface.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/tracing/libtracing.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwe bengine/src/core/release/obj/components/tracing/proto/libprotos.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/services/resource_coordinator/public/cpp/libresour ce_coordinator_cpp.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/platform/wtf/libwtf.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-every where-src-5.10.0/qtwebengine/src/core/release/obj/components/tracing/libstartup_tracing.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/gpu/command_buffer/client/ libgles2_c_lib.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/media/capture/libcapture_lib.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwe bengine/src/core/release/obj/media/gpu/libmedia_gpu.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/media/midi/libmidi.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt -everywhere-src-5.10.0/qtwebengine/src/core/release/obj/mojo/edk/system/libmojo_system_impl.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/sandbox/linux/libsandb ox_services.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/sandbox/linux/libsuid_sandbox_client.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0 /qtwebengine/src/core/release/obj/sandbox/linux/libseccomp_bpf.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/filesystem/lib.a /TOOLCHAIN/loop/target/ nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/services/service_manager/embedder/libembedder.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/releas e/obj/storage/common/libstorage_common.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/rtc_base/librtc_base.a /TOOLCHAIN/loop/target/nicebox/sa ndbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/rtc_base/librtc_base_approved.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/t hird_party/webrtc/libwebrtc_common.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc_overrides/libwebrtc.a /TOOLCHAIN/loop/target/nicebox/sandbox /qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libjingle_xmpp/librtc_task_runner.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_par ty/webrtc/p2p/librtc_p2p.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/api/libjingle_peerconnection_api.a /TOOLCHAIN/loop/target/nicebox/sand box/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/shell_dialogs/libshell_dialogs.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ppapi/shared_impl/ libppapi_shared.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/mime_util/libmime_util.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10. 0/qtwebengine/src/core/release/obj/storage/browser/libstorage_browser.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/leveldatabase/libleveldatabase.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/snappy/libbundled_snappy.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/ src/core/release/obj/components/discardable_memory/service/libdiscardable_memory_service.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/leveldb/lib.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/leveldb/public/cpp/libcpp.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/s rc/core/release/obj/components/link_header_util/liblink_header_util.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/metrics/libmetrics.a /TOOLCHAIN/loo p/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/metrics/proto/libproto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/o bj/components/metrics/libsingle_sample_metrics.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/network_session_configurator/browser/libbrowser.a /TOOLC HAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/network_session_configurator/common/libcommon.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0 /qtwebengine/src/core/release/obj/components/offline_pages/core/request_header/librequest_header.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/rappor /librappor.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/rappor/proto/libproto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwe bengine/src/core/release/obj/components/data_use_measurement/core/libcore.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/content/browser/background_sync/libbackg round_sync_proto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/content/browser/cache_storage/libcache_storage_proto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt- everywhere-src-5.10.0/qtwebengine/src/core/release/obj/content/browser/dom_storage/liblocal_storage_proto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/content/ browser/notifications/libnotification_proto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/content/browser/payments/libpayment_app_proto.a /TOOLCHAIN/loop/target /nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/content/browser/service_worker/libservice_worker_proto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/c ore/release/obj/content/browser/speech/proto/libproto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/device/gamepad/libdevice_gamepad.a /TOOLCHAIN/loop/target/ni cebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/device/geolocation/libgeolocation.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/device/v r/libdevice_vr_mojo_bindings.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/media/mojo/services/libmedia_mojo_services.a /TOOLCHAIN/loop/target/nicebox/sandbox/q t-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/media/cdm/libcdm_manager.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/net/libextras.a /TOOLCHAIN/loop/ target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/net/libhttp_server.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/device/sensors /libsensors.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/services/device/fingerprint/libfingerprint.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src- 5.10.0/qtwebengine/src/core/release/obj/device/base/libdevice_base.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/services/metrics/public/cpp/libmetrics_cpp.a /T OOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/ukm/libukm.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/o bj/third_party/zlib/google/libzip.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/zlib/libbundled_minizip.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt- everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/native_theme/libnative_theme.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/snapshot/libsnapshot.a / TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ui/touch_selection/libui_touch_selection.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengin e/src/core/release/obj/ui/aura_extra/libaura_extra.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/printing/libprinting.a /TOOLCHAIN/loop/target/nicebox/sandbox/q t-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/device/serial/libdevice_serial.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/jingle/libjingle_glue.a /T OOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/media/librtc_media_base.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengi ne/src/core/release/obj/third_party/webrtc/p2p/libstunprober.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/desktop_capture/libprimiti ves.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc_overrides/libinit_webrtc.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/ qtwebengine/src/core/release/obj/third_party/libsrtp/libsrtp.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/usrsctp/libusrsctp.a /TOOLCHAIN/loop/targ et/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/pc/libcreate_pc_factory.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/releas e/obj/third_party/webrtc/system_wrappers/libsystem_wrappers.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/api/audio_codecs/libbuiltin_audio_d ecoder_factory.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/libbuiltin_audio_decoder_factory_internal.a /TOOLCHAIN/loop /target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/libcng.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/co re/release/obj/third_party/webrtc/common_audio/libcommon_audio.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/openmax_dl/dl/libdl.a /TOOLCHAIN/loop/t arget/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/common_audio/libcommon_audio_sse2.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/sr c/core/release/obj/third_party/webrtc/modules/audio_coding/libg711.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/liblega cy_encoded_audio_frame.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/libpcm16b.a /TOOLCHAIN/loop/target/nicebox/sandbox/ qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/libwebrtc_opus.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/t hird_party/webrtc/modules/audio_coding/libaudio_network_adaptor.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/common_video/libcommon_video.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/rtc_base/librtc_task_queue.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwe bengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/libana_config_proto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/module s/audio_coding/libana_debug_dump_proto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/api/audio_codecs/opus/libaudio_encoder_opus_config.a /TO OLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/rtc_base/librtc_numerics.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengi ne/src/core/release/obj/third_party/webrtc/modules/audio_coding/libisac.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/li bisac_c.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/libisac_common.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywh ere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/libg722.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc /api/audio_codecs/libbuiltin_audio_encoder_factory.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/libbuiltin_audio_encode r_factory_internal.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/call/libcall.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10 .0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/rtp_rtcp/librtp_rtcp.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/rtc_base/li bsequenced_task_checker.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/libaudio_format_conversion.a /TOOLCHAIN/loop/targe t/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/remote_bitrate_estimator/libremote_bitrate_estimator.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-sr c-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/congestion_controller/libcongestion_controller.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/ob j/third_party/webrtc/modules/bitrate_controller/libbitrate_controller.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/pacing/libpacing. a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/utility/libutility.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qt webengine/src/core/release/obj/third_party/webrtc/audio/utility/libaudio_frame_operations.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modul es/media_file/libmedia_file.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/audio/libaudio.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhe re-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_device/libaudio_device.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party /webrtc/modules/audio_processing/libaudio_processing.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_processing/libaudioproc_debu g_proto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_processing/libaudio_processing_sse2.a /TOOLCHAIN/loop/target/nicebox/sand box/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/voice_engine/libvoice_engine.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/thir d_party/webrtc/modules/audio_coding/libaudio_coding.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/libneteq.a /TOOLCHAIN/ loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_coding/libisac_fix.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengi ne/src/core/release/obj/third_party/webrtc/modules/audio_coding/librent_a_codec.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/voice_engine/li baudio_level.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/voice_engine/libfile_player.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere -src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/voice_engine/libaudio_coder.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/voi ce_engine/libfile_recorder.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_conference_mixer/libaudio_conference_mixer.a /TOOLCHAI N/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/logging/librtc_event_log_impl.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengin e/src/core/release/obj/third_party/webrtc/logging/librtc_event_log_proto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/video/libvideo.a /TOOL CHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/rtc_base/libweak_ptr.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src /core/release/obj/third_party/webrtc/modules/video_coding/libvideo_coding.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/video_coding/ libvideo_coding_utility.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/video_coding/libwebrtc_h264.a /TOOLCHAIN/loop/target/nicebox/sa ndbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/video_coding/libwebrtc_i420.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release /obj/third_party/webrtc/modules/video_coding/libwebrtc_vp8.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/video_coding/libwebrtc_vp9.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/video_processing/libvideo_processing.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywh ere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/video_processing/libvideo_processing_sse2.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/o bj/third_party/webrtc/media/librtc_audio_video.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/video_capture/libvideo_capture.a /TOOLCH AIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/video_capture/libvideo_capture_module.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src -5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/audio_mixer/libaudio_mixer_impl.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/we brtc/modules/audio_mixer/libaudio_frame_manipulator.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/pc/librtc_pc_base.a /TOOLCHAIN/loop/target/ nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/media/librtc_data.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/thi rd_party/webrtc/pc/libpeerconnection.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/stats/librtc_stats.a /TOOLCHAIN/loop/target/nicebox/sandbo x/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/webrtc/modules/desktop_capture/libdesktop_capture.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/rele ase/obj/third_party/webrtc/modules/desktop_capture/libdesktop_capture_differ_sse2.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ppapi/host/libppapi_host.a /TOOL CHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/visitedlink/common/libcommon.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src /core/release/obj/content/public/renderer/librenderer_sources.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/content/child/libchild.a /TOOLCHAIN/loop/target/nice box/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/services/service_manager/public/interfaces/libservice_manager_mojom_blink.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtw ebengine/src/core/release/obj/services/service_manager/public/interfaces/libservice_manager_mojom_constants_blink.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/ components/webcrypto/libwebcrypto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/media/blink/libmedia_blink.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywher e-src-5.10.0/qtwebengine/src/core/release/obj/cc/blink/libcc_blink.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/controller/libblink_c ontroller.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/libblink_core.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src- 5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/libcore_generated.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source /bindings/core/v8/libbindings_core_impl.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/v8/libv8_libbase.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-sr c-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/platform/libblink_platform.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/iccjpeg /libiccjpeg.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/ots/libots.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/s rc/core/release/obj/third_party/woff2/libwoff2_dec.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/gin/libgin.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhe re-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/platform/heap/asm/libasm.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libx ml/libxml2.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libxslt/libbundled_libxslt.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10. 0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/animation/libanimation_0.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Sour ce/core/animation/libanimation_1.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/animation/libanimation_2.a /TOOLCHAIN/loop/target/ nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/animation/libanimation_3.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/c ore/release/obj/third_party/WebKit/Source/core/animation/libanimation_4.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/clipboard/l ibclipboard.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/context_features/libcontext_features.a /TOOLCHAIN/loop/target/nicebox/s andbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/css/libcss_0.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third _party/WebKit/Source/core/css/libcss_1.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/css/libcss_2.a /TOOLCHAIN/loop/target/nicebo x/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/css/libcss_3.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/th ird_party/WebKit/Source/core/css/libcss_4.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/dom/libdom_0.a /TOOLCHAIN/loop/target/nic ebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/dom/libdom_1.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj /third_party/WebKit/Source/core/dom/libdom_2.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/dom/libdom_3.a /TOOLCHAIN/loop/target/ nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/dom/libdom_4.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/ obj/third_party/WebKit/Source/core/editing/libediting_0.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/editing/libediting_1.a /TOO LCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/editing/libediting_2.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qt webengine/src/core/release/obj/third_party/WebKit/Source/core/editing/libediting_3.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/ editing/libediting_4.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/events/libevents.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-e verywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/exported/libexported.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_pa rty/WebKit/Source/core/fileapi/libfileapi.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/frame/libframe.a /TOOLCHAIN/loop/target/n icebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/fullscreen/libfullscreen.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/co re/release/obj/third_party/WebKit/Source/core/geometry/libgeometry_0.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/geometry/libge ometry_1.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/geometry/libgeometry_2.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywh ere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/geometry/libgeometry_3.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/ WebKit/Source/core/geometry/libgeometry_4.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/html/libhtml_0.a /TOOLCHAIN/loop/target/n icebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/html/libhtml_1.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release /obj/third_party/WebKit/Source/core/html/libhtml_2.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/html/libhtml_3.a /TOOLCHAIN/loop /target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/html/libhtml_4.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/cor e/release/obj/third_party/WebKit/Source/core/imagebitmap/libimagebitmap.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/input/libin put.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/inspector/libinspector.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-s rc-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/intersection_observer/libintersection_observer.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/relea se/obj/third_party/WebKit/Source/core/layout/liblayout_0.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/layout/liblayout_1.a /TOOL CHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/layout/liblayout_2.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtweb engine/src/core/release/obj/third_party/WebKit/Source/core/layout/liblayout_3.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/layou t/liblayout_4.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/layout/svg/libsvg_layout.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt- everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/loader/libloader.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party /WebKit/Source/core/mojo/libmojo.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/offscreencanvas/liboffscreencanvas.a /TOOLCHAIN/lo op/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/origin_trials/liborigin_trials.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/q twebengine/src/core/release/obj/third_party/WebKit/Source/core/page/libpage.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/paint/l ibpaint_0.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/paint/libpaint_1.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-s rc-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/probe/libprobe.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source /core/resize_observer/libresize_observer.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/streams/libstreams.a /TOOLCHAIN/loop/targe t/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/style/librendering.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/ release/obj/third_party/WebKit/Source/core/style/libsvg_style.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/svg/libsvg.a /TOOLCHA IN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/timing/libtiming.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengin e/src/core/release/obj/third_party/WebKit/Source/core/typed_arrays/libtyped_arrays.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/ url/liburl.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/workers/libworkers.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywher e-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/core/xml/libxml.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/ core/xmlhttprequest/libxmlhttprequest.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/libblink_modules.a /TOOLCHAIN/loop/target/ nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/bindings/modules/v8/libbindings_modules_impl.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qt webengine/src/core/release/obj/third_party/WebKit/Source/modules/accessibility/libaccessibility.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit /Source/modules/app_banner/libapp_banner.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/audio_output_devices/libaudio_output_de vices.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/background_fetch/libbackground_fetch.a /TOOLCHAIN/loop/target/nicebox/sand box/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/background_sync/libbackground_sync.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/ core/release/obj/third_party/WebKit/Source/modules/battery/libbattery.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/beacon/lib beacon.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/bluetooth/libbluetooth.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everyw here-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/broadcastchannel/libbroadcastchannel.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/releas e/obj/third_party/WebKit/Source/modules/budget/libbudget.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/cachestorage/libcachest orage.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/canvas/libcanvas.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-sr c-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/canvas2d/libcanvas2d.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKi t/Source/modules/compositorworker/libcompositorworker.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/credentialmanager/libcrede ntialmanager.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/crypto/libcrypto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everyw here-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/csspaint/libcsspaint.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_part y/WebKit/Source/modules/device_orientation/libdevice_orientation.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/document_metada ta/libdocument_metadata.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/donottrack/libdonottrack.a /TOOLCHAIN/loop/target/nicebo x/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/encoding/libencoding.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/rel ease/obj/third_party/WebKit/Source/modules/encryptedmedia/libencryptedmedia.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/even tsource/libeventsource.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/exported/libexported.a /TOOLCHAIN/loop/target/nicebox/san dbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/fetch/libfetch.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/th ird_party/WebKit/Source/modules/filesystem/libfilesystem.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/gamepad/libgamepad.a /T OOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/geolocation/libgeolocation.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-sr c-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/imagebitmap/libimagebitmap.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party /WebKit/Source/modules/imagecapture/libimagecapture.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/indexeddb/libindexeddb.a /TO OLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/installation/libinstallation.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-s rc-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/installedapp/libinstalledapp.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_pa rty/WebKit/Source/modules/keyboard_lock/libkeyboard_lock.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/media_capabilities/libm edia_capabilities.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/media_controls/libmedia_controls.a /TOOLCHAIN/loop/target/nice box/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/mediacapturefromelement/libmediacapturefromelement.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src -5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/mediarecorder/libmediarecorder.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_pa rty/WebKit/Source/modules/mediasession/libmediasession.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/mediasource/libmediasourc e.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/mediastream/libmediastream.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywh ere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/navigatorcontentutils/libnavigatorcontentutils.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/co re/release/obj/third_party/WebKit/Source/modules/netinfo/libnetinfo.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/nfc/libnfc.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/notifications/libnotifications.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everyw here-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/offscreencanvas/liboffscreencanvas.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/ obj/third_party/WebKit/Source/modules/offscreencanvas2d/liboffscreencanvas2d.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/pay ments/libpayments.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/peerconnection/libpeerconnection.a /TOOLCHAIN/loop/target/nice box/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/permissions/libpermissions.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/ core/release/obj/third_party/WebKit/Source/modules/plugins/libplugins.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/presentati on/libpresentation.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/push_messaging/libpush_messaging.a /TOOLCHAIN/loop/target/nic ebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/quota/libquota.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/releas e/obj/third_party/WebKit/Source/modules/remoteplayback/libremoteplayback.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/screen_ orientation/libscreen_orientation.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/sensor/libsensor.a /TOOLCHAIN/loop/target/nice box/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/serviceworkers/libserviceworkers.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengin e/src/core/release/obj/third_party/WebKit/Source/modules/shapedetection/libshapedetection.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Sourc e/modules/speech/libspeech.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/srcobject/libsrcobject.a /TOOLCHAIN/loop/target/niceb ox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/storage/libstorage.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/rele ase/obj/third_party/WebKit/Source/modules/time_zone_monitor/libtime_zone_monitor.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules /vibration/libvibration.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/vr/libvr.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-eve rywhere-src-5.10.0/qtwebengine/src/core/release/obj/device/vr/libdevice_vr_mojo_bindings_blink.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/ Source/modules/wake_lock/libwake_lock.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/webaudio/libwebaudio.a /TOOLCHAIN/loop/tar get/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/webauth/libwebauth.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/ core/release/obj/third_party/WebKit/Source/modules/webdatabase/libwebdatabase.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/we bgl/libwebgl.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/webmidi/libwebmidi.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-ever ywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/webshare/libwebshare.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_pa rty/WebKit/Source/modules/websockets/libwebsockets.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/modules/webusb/libwebusb.a /TOOLCHAIN /loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/WebKit/Source/web/libblink_web.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/c ore/release/obj/ppapi/proxy/libppapi_proxy.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/content/renderer/librenderer.a /TOOLCHAIN/loop/target/nicebox/sandbox/q t-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/content/gpu/libgpu_sources.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/media/gpu/ipc/service/libservi ce.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/mojo/edk/js/libjs.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/releas e/obj/media/remoting/libmedia_remoting_proto.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/content/public/gpu/libgpu_sources.a /TOOLCHAIN/loop/target/nicebox/sa ndbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/hunspell/libhunspell.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/pdf/libpdf.a /TOO LCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/libpdfium.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/rele ase/obj/third_party/pdfium/libfxcrt.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/libfdrm.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywh ere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/libformfiller.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/libfpdfapi.a / TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/libfpdfdoc.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/ release/obj/third_party/pdfium/libfpdftext.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/libfxcodec.a /TOOLCHAIN/loop/target/nicebox/sandbox/ qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/third_party/libfx_libopenjpeg.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_p arty/pdfium/third_party/libfx_lcms2.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/libfxedit.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-every where-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/libfxge.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/third_party/libfx_ agg.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/libjavascript.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine /src/core/release/obj/third_party/pdfium/libfxjs.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/v8/libv8_libplatform.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt- everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/libpdfwindow.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/pdfium/third_pa rty/libbigint.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/printing/browser/libbrowser.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. 10.0/qtwebengine/src/core/release/obj/components/printing/common/libcommon.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/printing/renderer/librendere r.a /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/components/cdm/common/libcommon.a -Wl,--end-group -L/usr/X11R7/lib -L/usr/lib/nss -L/usr/lib/nspr -lQt5Quick -L/ TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Gui -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtdeclarative/lib -lQt5Qml -lQt5Network -lQt5Core -lpthread -lQt 5Gui -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Core -lpthread -lQt5WebChannel -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtdeclarative/lib -lQt5Qml -L /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Network -lQt5Core -lpthread -lQt5Qml -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Network -lQt5C ore -lpthread -lQt5Network -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Core -lpthread -lQt5Positioning -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase /lib -lQt5Core -lpthread -lQt5Core -lpthread -lGL -lpthread -ldl -lrt -lsmime3 -lnssutil3 -lnss3 -lplds4 -lplc4 -lnspr4 -lresolv -lX11 -lX11-xcb -lxcb -lXcomposite -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrende r -lXtst -lfreetype -lfontconfig -lexpat -lXrandr -lasound -lm -lz -ldbus-1 -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/api/release -Wl,-whole-archive -lqtwebenginecoreap i -Wl,-no-whole-archive -lEGL -lQt5Quick -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Gui -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtdeclarative/lib -l Qt5Qml -lQt5Network -lQt5Core -lpthread -lQt5Gui -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Core -lpthread -lQt5Qml -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src -5.10.0/qtbase/lib -lQt5Network -lQt5Core -lpthread -lQt5Network -L/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Core -lpthread -lQt5Core -lpthread -lGL /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libvpx/libbundled_libvpx.a(vpx_dsp_rtcd.o): In function `setup_rtcd_internal': vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1bc): undefined reference to `vpx_convolve8_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x26c): undefined reference to `vpx_convolve8_horiz_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x2a4): undefined reference to `vpx_convolve8_vert_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x6db): undefined reference to `vpx_get16x16var_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1186): undefined reference to `vpx_highbd_convolve8_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1192): undefined reference to `vpx_highbd_convolve8_avg_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x119e): undefined reference to `vpx_highbd_convolve8_avg_horiz_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x11aa): undefined reference to `vpx_highbd_convolve8_avg_vert_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x11b6): undefined reference to `vpx_highbd_convolve8_horiz_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x11c2): undefined reference to `vpx_highbd_convolve8_vert_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x11ea): undefined reference to `vpx_highbd_convolve_avg_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1212): undefined reference to `vpx_highbd_convolve_copy_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1b39): undefined reference to `vpx_lpf_horizontal_16_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1b61): undefined reference to `vpx_lpf_horizontal_16_dual_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1cc8): undefined reference to `vpx_mse16x16_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1ed9): undefined reference to `vpx_sad32x16_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1f01): undefined reference to `vpx_sad32x16_avg_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1f41): undefined reference to `vpx_sad32x32_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1f69): undefined reference to `vpx_sad32x32_avg_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1f91): undefined reference to `vpx_sad32x32x4d_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1fb9): undefined reference to `vpx_sad32x64_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x1fe1): undefined reference to `vpx_sad32x64_avg_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x20e1): undefined reference to `vpx_sad64x32_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x2109): undefined reference to `vpx_sad64x32_avg_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x2149): undefined reference to `vpx_sad64x64_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x2171): undefined reference to `vpx_sad64x64_avg_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x2199): undefined reference to `vpx_sad64x64x4d_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x23d9): undefined reference to `vpx_sub_pixel_avg_variance32x32_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x24b1): undefined reference to `vpx_sub_pixel_avg_variance64x64_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x2601): undefined reference to `vpx_sub_pixel_variance32x32_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x26d9): undefined reference to `vpx_sub_pixel_variance64x64_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x286d): undefined reference to `vpx_variance16x16_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x28c5): undefined reference to `vpx_variance32x16_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x28ed): undefined reference to `vpx_variance32x32_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x295d): undefined reference to `vpx_variance64x32_avx2' vpx_dsp_rtcd.c:(.text.setup_rtcd_internal+0x2985): undefined reference to `vpx_variance64x64_avx2' /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release/obj/third_party/libvpx/libbundled_libvpx.a(vp9_rtcd.o): In function `setup_rtcd_internal': vp9_rtcd.c:(.text.setup_rtcd_internal+0x15b): undefined reference to `vp9_block_error_avx2' collect2: error: ld returned 1 exit status make[3]: *** [../../lib/libQt5WebEngineCore.so.5.10.0] Error 1 make[3]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' make[2]: *** [sub-core_module-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 Fri, Dec 22, 2017 at 11:34 AM, Thiago Macieira wrote: > On sexta-feira, 22 de dezembro de 2017 10:30:12 -02 Konstantin Tokarev > wrote: > > Well, -m32 is also a kind of cross-compilation. It requires completely > > different set of dependency packages to be preinstalled. > > Not exactly. Yes, it requires a different set of packages to be installed, > but > they're natively installed and can be run on the CPU, without emulation. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.mironchik at gmail.com Wed Jan 3 17:26:49 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Wed, 3 Jan 2018 19:26:49 +0300 Subject: [Development] Project ERROR: Could not find feature future. Message-ID: Hello, What does it mean: Project ERROR: Could not find feature future. This is from qmake-ing corelib.pro in dev branch. Thank you. From igor.mironchik at gmail.com Wed Jan 3 18:29:19 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Wed, 3 Jan 2018 20:29:19 +0300 Subject: [Development] Project ERROR: Could not find feature future. In-Reply-To: References: Message-ID: <4ae75e88-c48b-2474-4b1f-5e5d470169c3@gmail.com> Hi, I will ask with another words: does dev branch compiles? How do you organize work on Qt in case of contributions? For example, I created a contribution based on dev branch and can't even check if it compiles. Maybe you, guys, do such things somehow in different way? Maybe I understood something wrong? Thank you. On 03.01.2018 19:26, Igor Mironchik wrote: > Hello, > > What does it mean: Project ERROR: Could not find feature future. > > This is from qmake-ing corelib.pro in dev branch. > > Thank you. > From kevin.kofler at chello.at Wed Jan 3 18:48:01 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 03 Jan 2018 18:48:01 +0100 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine References: <1579689.60vB0ZmokD@tjmaciei-mobl1> <2707441513945812@web4g.yandex.ru> <2126029.WM82Itbiqh@tjmaciei-mobl1> Message-ID: Toan Pham wrote: > I over came the memory limitation by forcing ninja to run in single thread > (pass -j 1 to ninja). However, at linking stage using a 32bit linker, the > linker failed because it could not find references to avx2 in libvpx, a > third-party library that I hacked to get AVX2 disabled. Since you've been > recommending that I should use 64bit linker, this error is completely > unrelated to the memory address limit of a 32bit linker. While the 32bit > linker was doing its job linking libQt5WebEngine.so, its maximum memory > usage (RSS) was 1.8GB, not anywhere close to the maximum addressable limit > of 32bit executables. libvpx detects vector instructions at runtime. Therefore, it is not necessary to disable AVX2 support even if your machine does not support AVX2. Kevin Kofler From Martin.Smith at qt.io Wed Jan 3 19:01:44 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Wed, 3 Jan 2018 18:01:44 +0000 Subject: [Development] Project ERROR: Could not find feature future. In-Reply-To: <4ae75e88-c48b-2474-4b1f-5e5d470169c3@gmail.com> References: , <4ae75e88-c48b-2474-4b1f-5e5d470169c3@gmail.com> Message-ID: When I get that error, I do: git clean -dxf and run configure again. ________________________________________ From: Development on behalf of Igor Mironchik Sent: Wednesday, January 3, 2018 6:29:19 PM To: development at qt-project.org Subject: Re: [Development] Project ERROR: Could not find feature future. Hi, I will ask with another words: does dev branch compiles? How do you organize work on Qt in case of contributions? For example, I created a contribution based on dev branch and can't even check if it compiles. Maybe you, guys, do such things somehow in different way? Maybe I understood something wrong? Thank you. On 03.01.2018 19:26, Igor Mironchik wrote: > Hello, > > What does it mean: Project ERROR: Could not find feature future. > > This is from qmake-ing corelib.pro in dev branch. > > Thank you. > _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From tpham3783 at gmail.com Wed Jan 3 19:02:33 2018 From: tpham3783 at gmail.com (Toan Pham) Date: Wed, 3 Jan 2018 13:02:33 -0500 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <1579689.60vB0ZmokD@tjmaciei-mobl1> <2707441513945812@web4g.yandex.ru> <2126029.WM82Itbiqh@tjmaciei-mobl1> Message-ID: @Kevin, The compiler I built a few years back was optimized for pentium4; it wouldn't accept the -mavx2 option. That's why I had to hack libvpx to disable avx completely. Anyway, Here's the patch to libvpx if anyone is running into the same issue at link time: --- source/config/linux/ia32/vpx_dsp_rtcd.h.vanilla 2018-01-03 13:13:06.000000000 -0500 +++ source/config/linux/ia32/vpx_dsp_rtcd.h 2018-01-03 12:04:56.000000000 -0500 @@ -1969,6 +1969,8 @@ #include "vpx_ports/x86.h" static void setup_rtcd_internal(void) { + // pham + return; int flags = x86_simd_caps(); (void)flags; debug-linux26:[libvpx]# diff -urN source/config/linux/ia32/vp9_rtcd.h.vanilla source/config/linux/ia32/vp9_rtcd.h --- source/config/linux/ia32/vp9_rtcd.h.vanilla 2018-01-03 13:12:24.000000000 -0500 +++ source/config/linux/ia32/vp9_rtcd.h 2018-01-03 12:14:11.000000000 -0500 @@ -153,6 +153,9 @@ { int flags = x86_simd_caps(); + // pham + return; + (void)flags; vp9_block_error = vp9_block_error_c; On Wed, Jan 3, 2018 at 12:48 PM, Kevin Kofler wrote: > Toan Pham wrote: > > I over came the memory limitation by forcing ninja to run in single > thread > > (pass -j 1 to ninja). However, at linking stage using a 32bit linker, > the > > linker failed because it could not find references to avx2 in libvpx, a > > third-party library that I hacked to get AVX2 disabled. Since you've > been > > recommending that I should use 64bit linker, this error is completely > > unrelated to the memory address limit of a 32bit linker. While the 32bit > > linker was doing its job linking libQt5WebEngine.so, its maximum memory > > usage (RSS) was 1.8GB, not anywhere close to the maximum addressable > limit > > of 32bit executables. > > libvpx detects vector instructions at runtime. Therefore, it is not > necessary to disable AVX2 support even if your machine does not support > AVX2. > > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Jan 3 20:30:26 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Jan 2018 17:30:26 -0200 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: Message-ID: <5430322.KfG4hcZHa9@tjmaciei-mobl1> On Wednesday, 3 January 2018 16:02:33 -02 Toan Pham wrote: > The compiler I built a few years back was optimized for pentium4; it > wouldn't accept the -mavx2 option. That's why I had to hack libvpx to > disable avx completely. AVX2 is a "relatively" modern instruction set, only available in GCC since 2011 (released in 2012, GCC 4.7). Are you sure the libvpx buildsystem couldn't cope with the absence of this option? In any case, if your compiler doesn't accept -mavx2, then it's older than GCC 4.7 and is therefore not supported with Qt 5.7 and up. Upgrade. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jan 3 20:22:55 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Jan 2018 17:22:55 -0200 Subject: [Development] Project ERROR: Could not find feature future. In-Reply-To: <4ae75e88-c48b-2474-4b1f-5e5d470169c3@gmail.com> References: <4ae75e88-c48b-2474-4b1f-5e5d470169c3@gmail.com> Message-ID: <2532030.nre99fXWUq@tjmaciei-mobl1> On Wednesday, 3 January 2018 15:29:19 -02 Igor Mironchik wrote: > How do you organize work on Qt in case of contributions? I develop everything on top of the current stable branch (5.10 today), except for a brief time between the first beta and the release of a new minor version. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jan 3 20:21:53 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Jan 2018 17:21:53 -0200 Subject: [Development] Project ERROR: Could not find feature future. In-Reply-To: References: Message-ID: <2329042.sbRi8KNLez@tjmaciei-mobl1> On Wednesday, 3 January 2018 14:26:49 -02 Igor Mironchik wrote: > Hello, > > What does it mean: Project ERROR: Could not find feature future. > > This is from qmake-ing corelib.pro in dev branch. Are you sure you've finished configure in the qtbase top (or qt5.git)? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tpham3783 at gmail.com Wed Jan 3 20:53:40 2018 From: tpham3783 at gmail.com (Toan Pham) Date: Wed, 3 Jan 2018 14:53:40 -0500 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: <5430322.KfG4hcZHa9@tjmaciei-mobl1> References: <5430322.KfG4hcZHa9@tjmaciei-mobl1> Message-ID: Thiago, I am using gcc 4.8.5, but the compiler was optimized for pentium4 so all of those vector instructions had to be disabled at build time. BTW, I got webengine to compile successfully with several patches to libvpx. Now, I just ran into another brick wall with the errors attached at the end of this email. Here is my qt configure option: -prefix /opt/qt5.10.0 -no-separate-debug-info -system-zlib -system-libpng -confirm-license -nomake examples -I /usr/X11/include -release -webengine-webrtc -qt-libjpeg -no-sse2 -no-sse3 -no-sse3 -no-sse4.1 -no-sse4.2 -no-avx -no-avx2 Please help if you know what's going on. thanks.. make[3]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/src/tools/qvkgen' cd gui/ && ( test -e Makefile || /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/bin/qmake -o Makefile /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/src/gui/ gui.pro ) && make -f Makefile make[3]: Entering directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/src/gui' rm -f libQt5Gui.so.5.10.0 libQt5Gui.so libQt5Gui.so.5 libQt5Gui.so.5.10 g++ -Wl,--no-undefined -Wl,--version-script,QtGui.version -Wl,-O1 -Wl,--enable-new-dtags -Wl,-z,origin -Wl,-rpath,\$ORIGIN -shared -Wl,-Bsymbolic-functions -Wl,--dynamic-list,/TOOLCHAIN/loop/target/nicebox/sandbox /qt-everywhere-src-5.10.0/qtbase/src/gui/QtGui.dynlist -Wl,-soname,libQt5Gui.so.5 -o libQt5Gui.so.5.10.0 .obj/qimage_compat.o .obj/qaccessible.o .obj/qaccessiblecache.o .obj/qaccessibleobject.o .obj/qaccessibleplu gin.o .obj/qplatformaccessibility.o .obj/qaccessiblebridge.o .obj/qgenericpluginfactory.o .obj/qgenericplugin.o .obj/qwindowsysteminterface.o .obj/qplatforminputcontextfactory.o .obj/qplatforminputcontextplugin.o .obj/qplatforminputcontext.o .obj/qplatformintegration.o .obj/qplatformdrag.o .obj/qplatformscreen.o .obj/qplatformintegrationfactory.o .obj/qplatformintegrationplugin.o .obj/qplatformtheme.o .obj/qplatformthemefa ctory.o .obj/qplatformthemeplugin.o .obj/qplatformwindow.o .obj/qplatformoffscreensurface.o .obj/qplatformcursor.o .obj/qplatformclipboard.o .obj/qplatformnativeinterface.o .obj/qsessionmanager.o .obj/qshapedpixma pdndwindow.o .obj/qsimpledrag.o .obj/qsurfaceformat.o .obj/qguiapplication.o .obj/qwindow.o .obj/qoffscreensurface.o .obj/qplatformsurface.o .obj/qsurface.o .obj/qclipboard.o .obj/qcursor.o .obj/qdrag.o .obj/qdnd. o .obj/qevent.o .obj/qinputmethod.o .obj/qkeysequence.o .obj/qkeymapper.o .obj/qpalette.o .obj/qguivariant.o .obj/qscreen.o .obj/qshortcutmap.o .obj/qstylehints.o .obj/qtouchdevice.o .obj/qplatformsharedgraphicsca che.o .obj/qplatformdialoghelper.o .obj/qplatformservices.o .obj/qplatformsystemtrayicon.o .obj/qplatformsessionmanager.o .obj/qplatformmenu.o .obj/qpixelformat.o .obj/qpaintdevicewindow.o .obj/qrasterwindow.o .ob j/qplatformgraphicsbuffer.o .obj/qplatformgraphicsbufferhelper.o .obj/qinputdevicemanager.o .obj/qhighdpiscaling.o .obj/qplatformopenglcontext.o .obj/qopenglcontext.o .obj/qopenglwindow.o .obj/qbitmap.o .obj/qimag e.o .obj/qimage_conversions.o .obj/qimageiohandler.o .obj/qimagereader.o .obj/qimagewriter.o .obj/qpaintengine_pic.o .obj/qpicture.o .obj/qpictureformatplugin.o .obj/qpixmap.o .obj/qpixmapcache.o .obj/qplatformpix map.o .obj/qpixmap_raster.o .obj/qpixmap_blitter.o .obj/qimagepixmapcleanuphooks.o .obj/qicon.o .obj/qiconloader.o .obj/qiconengine.o .obj/qiconengineplugin.o .obj/qmovie.o .obj/qbmphandler.o .obj/qppmhandler.o .o bj/qxbmhandler.o .obj/qxpmhandler.o .obj/qpnghandler.o .obj/qfont.o .obj/qfontengine.o .obj/qfontengineglyphcache.o .obj/qfontsubset.o .obj/qfontmetrics.o .obj/qfontdatabase.o .obj/qtextengine.o .obj/qtextlayout.o .obj/qtextformat.o .obj/qtextobject.o .obj/qtextoption.o .obj/qfragmentmap.o .obj/qtextdocument.o .obj/qtextdocument_p.o .obj/qtexthtmlparser.o .obj/qabstracttextdocumentlayout.o .obj/qtextdocumentlayout.o .obj/q textcursor.o .obj/qtextdocumentfragment.o .obj/qtextimagehandler.o .obj/qtexttable.o .obj/qtextlist.o .obj/qtextdocumentwriter.o .obj/qsyntaxhighlighter.o .obj/qstatictext.o .obj/qrawfont.o .obj/qglyphrun.o .obj/q distancefield.o .obj/qinputcontrol.o .obj/qfontengine_qpf2.o .obj/qplatformfontdatabase.o .obj/qharfbuzzng.o .obj/qtextodfwriter.o .obj/qzip.o .obj/qcssparser.o .obj/qbackingstore.o .obj/qbezier.o .obj/qblendfunct ions.o .obj/qblittable.o .obj/qbrush.o .obj/qcolor.o .obj/qcolorprofile.o .obj/qcompositionfunctions.o .obj/qcosmeticstroker.o .obj/qdrawhelper.o .obj/qemulationpaintengine.o .obj/qgrayraster.o .obj/qimagescale.o .obj/qmatrix.o .obj/qmemrotate.o .obj/qoutlinemapper.o .obj/qpagedpaintdevice.o .obj/qpagelayout.o .obj/qpagesize.o .obj/qpaintdevice.o .obj/qpaintengine.o .obj/qpaintengineex.o .obj/qpaintengine_blitter.o .obj/qp aintengine_raster.o .obj/qpainter.o .obj/qpainterpath.o .obj/qpathclipper.o .obj/qpdf.o .obj/qpdfwriter.o .obj/qpen.o .obj/qpolygon.o .obj/qrasterizer.o .obj/qregion.o .obj/qstroker.o .obj/qtextureglyphcache.o .ob j/qtransform.o .obj/qtriangulatingstroker.o .obj/qtriangulator.o .obj/qplatformbackingstore.o .obj/qpathsimplifier.o .obj/qcssutil.o .obj/qdesktopservices.o .obj/qvalidator.o .obj/qgridlayoutengine.o .obj/qabstrac tlayoutstyleinfo.o .obj/qlayoutpolicy.o .obj/qshaderformat.o .obj/qshadergenerator.o .obj/qshadergraph.o .obj/qshadergraphloader.o .obj/qshaderlanguage.o .obj/qshadernode.o .obj/qshadernodeport.o .obj/qshadernodes loader.o .obj/qgenericmatrix.o .obj/qmatrix4x4.o .obj/qquaternion.o .obj/qvector2d.o .obj/qvector3d.o .obj/qvector4d.o .obj/qopengl.o .obj/qopenglfunctions.o .obj/qopenglframebufferobject.o .obj/qopenglpaintdevice .o .obj/qopenglbuffer.o .obj/qopenglshaderprogram.o .obj/qopenglgradientcache.o .obj/qopengltexturecache.o .obj/qopenglengineshadermanager.o .obj/qopengl2pexvertexarray.o .obj/qopenglpaintengine.o .obj/qopenglcust omshaderstage.o .obj/qopengltextureglyphcache.o .obj/qopenglversionfunctions.o .obj/qopenglversionfunctionsfactory.o .obj/qopenglvertexarrayobject.o .obj/qopengldebug.o .obj/qopengltextureblitter.o .obj/qopengltex ture.o .obj/qopengltexturehelper.o .obj/qopenglpixeltransferoptions.o .obj/qopenglprogrambinarycache.o .obj/qopenglfunctions_1_0.o .obj/qopenglfunctions_1_1.o .obj/qopenglfunctions_1_2.o .obj/qopenglfunctions_1_3. o .obj/qopenglfunctions_1_4.o .obj/qopenglfunctions_1_5.o .obj/qopenglfunctions_2_0.o .obj/qopenglfunctions_2_1.o .obj/qopenglfunctions_3_0.o .obj/qopenglfunctions_3_1.o .obj/qopenglfunctions_3_2_core.o .obj/qopen glfunctions_3_3_core.o .obj/qopenglfunctions_4_0_core.o .obj/qopenglfunctions_4_1_core.o .obj/qopenglfunctions_4_2_core.o .obj/qopenglfunctions_4_3_core.o .obj/qopenglfunctions_4_4_core.o .obj/qopenglfunctions_4_5 _core.o .obj/qopenglfunctions_3_2_compatibility.o .obj/qopenglfunctions_3_3_compatibility.o .obj/qopenglfunctions_4_0_compatibility.o .obj/qopenglfunctions_4_1_compatibility.o .obj/qopenglfunctions_4_2_compatibili ty.o .obj/qopenglfunctions_4_3_compatibility.o .obj/qopenglfunctions_4_4_compatibility.o .obj/qopenglfunctions_4_5_compatibility.o .obj/qopengltimerquery.o .obj/qguivariantanimation.o .obj/qstandarditemmodel.o .ob j/qrc_qpdf.o .obj/moc_qaccessible.o .obj/moc_qaccessiblecache_p.o .obj/moc_qaccessibleplugin.o .obj/moc_qaccessiblebridge.o .obj/moc_qgenericplugin.o .obj/moc_qplatforminputcontext.o .obj/moc_qplatforminputcontext plugin_p.o .obj/moc_qplatformintegrationplugin.o .obj/moc_qplatformthemeplugin.o .obj/moc_qplatformnativeinterface.o .obj/moc_qplatformmenu.o .obj/moc_qshapedpixmapdndwindow_p.o .obj/moc_qsurfaceformat.o .obj/moc_ qoffscreensurface.o .obj/moc_qclipboard.o .obj/moc_qdrag.o .obj/moc_qdnd_p.o .obj/moc_qevent.o .obj/moc_qkeysequence.o .obj/moc_qkeymapper_p.o .obj/moc_qpalette.o .obj/moc_qsessionmanager.o .obj/moc_qscreen.o .obj /moc_qstylehints.o .obj/moc_qtouchdevice.o .obj/moc_qplatformsharedgraphicscache.o .obj/moc_qplatformdialoghelper.o .obj/moc_qpaintdevicewindow.o .obj/moc_qrasterwindow.o .obj/moc_qplatformgraphicsbuffer.o .obj/mo c_qinputdevicemanager_p.o .obj/moc_qopenglwindow.o .obj/moc_qimageiohandler.o .obj/moc_qpictureformatplugin.o .obj/moc_qiconengineplugin.o .obj/moc_qfont.o .obj/moc_qfontdatabase.o .obj/moc_qtextformat.o .obj/moc_ qtextobject.o .obj/moc_qtextdocument.o .obj/moc_qtextimagehandler_p.o .obj/moc_qtexttable.o .obj/moc_qtextlist.o .obj/moc_qinputcontrol_p.o .obj/moc_qbrush.o .obj/moc_qpainter.o .obj/moc_qpdfwriter.o .obj/moc_qpla tformbackingstore.o .obj/moc_qvalidator.o .obj/moc_qshaderlanguage_p.o .obj/moc_qopenglshaderprogram.o .obj/moc_qopenglengineshadermanager_p.o .obj/moc_qopengltexture.o .obj/moc_qopengltimerquery.o -L/TOOLCHAIN/l oop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/lib -lQt5Core -lpthread -L/usr/X11R7/lib -lGL -lpng12 -lqtharfbuzz -lz .obj/qimage.o: In function `QImage::fill(unsigned int)': qimage.cpp:(.text+0x46fa): undefined reference to `qt_memfill16(unsigned short*, unsigned short, int)' qimage.cpp:(.text+0x471f): undefined reference to `qt_memfill16(unsigned short*, unsigned short, int)' qimage.cpp:(.text+0x4802): undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)' qimage.cpp:(.text+0x4828): undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)' .obj/qimage_conversions.o:(.data.rel+0x20c): undefined reference to `convert_ARGB_to_ARGB_PM_inplace_sse2(QImageData*, QFlags)' .obj/qimage_conversions.o:(.data.rel+0x6ec): undefined reference to `convert_ARGB_to_ARGB_PM_inplace_sse2(QImageData*, QFlags)' .obj/qcompositionfunctions.o: In function `comp_func_solid_Clear(unsigned int*, int, unsigned int, unsigned int)': qcompositionfunctions.cpp:(.text+0x2064): undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)' .obj/qcompositionfunctions.o: In function `comp_func_Clear(unsigned int*, unsigned int const*, int, unsigned int)': qcompositionfunctions.cpp:(.text+0x210c): undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)' .obj/qcompositionfunctions.o: In function `comp_func_solid_Source(unsigned int*, int, unsigned int, unsigned int)': qcompositionfunctions.cpp:(.text+0x21b9): undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)' .obj/qcompositionfunctions.o: In function `rasterop_solid_NotSource(unsigned int*, int, unsigned int, unsigned int)': qcompositionfunctions.cpp:(.text+0x22b1): undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)' .obj/qcompositionfunctions.o: In function `comp_func_solid_SourceOver(unsigned int*, int, unsigned int, unsigned int)': qcompositionfunctions.cpp:(.text+0x22fb): undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)' .obj/qdrawhelper.o:qdrawhelper.cpp:(.text+0x2325): more undefined references to `qt_memfill32(unsigned int*, unsigned int, int)' follow .obj/qdrawhelper.o: In function `qt_rectfill_quint16(QRasterBuffer*, int, int, int, int, QRgba64 const&)': qdrawhelper.cpp:(.text+0x10504): undefined reference to `qt_memfill16(unsigned short*, unsigned short, int)' qdrawhelper.cpp:(.text+0x10522): undefined reference to `qt_memfill16(unsigned short*, unsigned short, int)' .obj/qdrawhelper.o: In function `qt_bitmapblit_quint16(QRasterBuffer*, int, int, QRgba64 const&, unsigned char const*, int, int, int)': qdrawhelper.cpp:(.text+0x105f7): undefined reference to `qt_memfill16(unsigned short*, unsigned short, int)' qdrawhelper.cpp:(.text+0x10649): undefined reference to `qt_memfill16(unsigned short*, unsigned short, int)' qdrawhelper.cpp:(.text+0x10686): undefined reference to `qt_memfill16(unsigned short*, unsigned short, int)' .obj/qdrawhelper.o:qdrawhelper.cpp:(.text+0x106cc): more undefined references to `qt_memfill16(unsigned short*, unsigned short, int)' follow .obj/qdrawhelper.o: In function `_GLOBAL__sub_I_qdrawhelper.cpp': qdrawhelper.cpp:(.text.startup+0x19): undefined reference to `qt_bitmapblit32_sse2(QRasterBuffer*, int, int, QRgba64 const&, unsigned char const*, int, int, int)' qdrawhelper.cpp:(.text.startup+0x31): undefined reference to `qt_bitmapblit16_sse2(QRasterBuffer*, int, int, QRgba64 const&, unsigned char const*, int, int, int)' qdrawhelper.cpp:(.text.startup+0x3d): undefined reference to `qt_bitmapblit8888_sse2(QRasterBuffer*, int, int, QRgba64 const&, unsigned char const*, int, int, int)' qdrawhelper.cpp:(.text.startup+0x5b): undefined reference to `qt_scale_image_argb32_on_argb32_sse2(unsigned char*, int, unsigned char const*, int, int, QRectF const&, QRectF const&, QRect const&, int)' qdrawhelper.cpp:(.text.startup+0x7f): undefined reference to `qt_blend_rgb32_on_rgb32_sse2(unsigned char*, int, unsigned char const*, int, int, int, int)' qdrawhelper.cpp:(.text.startup+0x91): undefined reference to `qt_blend_argb32_on_argb32_sse2(unsigned char*, int, unsigned char const*, int, int, int, int)' qdrawhelper.cpp:(.text.startup+0xbb): undefined reference to `qt_fetch_radial_gradient_sse2(unsigned int*, Operator const*, QSpanData const*, int, int, int)' qdrawhelper.cpp:(.text.startup+0xcd): undefined reference to `comp_func_SourceOver_sse2(unsigned int*, unsigned int const*, int, unsigned int)' qdrawhelper.cpp:(.text.startup+0xd5): undefined reference to `comp_func_solid_SourceOver_sse2(unsigned int*, int, unsigned int, unsigned int)' qdrawhelper.cpp:(.text.startup+0xe3): undefined reference to `comp_func_Source_sse2(unsigned int*, unsigned int const*, int, unsigned int)' qdrawhelper.cpp:(.text.startup+0xec): undefined reference to `comp_func_Plus_sse2(unsigned int*, unsigned int const*, int, unsigned int)' collect2: error: ld returned 1 exit status make[3]: *** [../../lib/libQt5Gui.so.5.10.0] Error 1 make[3]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/src/gui' make[2]: *** [sub-gui-make_first] Error 2 make[2]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/src' make[1]: *** [sub-src-make_first] Error 2 make[1]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase' make: *** [module-qtbase-make_first] Error 2 On Wed, Jan 3, 2018 at 2:30 PM, Thiago Macieira wrote: > On Wednesday, 3 January 2018 16:02:33 -02 Toan Pham wrote: > > The compiler I built a few years back was optimized for pentium4; it > > wouldn't accept the -mavx2 option. That's why I had to hack libvpx to > > disable avx completely. > > AVX2 is a "relatively" modern instruction set, only available in GCC since > 2011 (released in 2012, GCC 4.7). Are you sure the libvpx buildsystem > couldn't > cope with the absence of this option? > > In any case, if your compiler doesn't accept -mavx2, then it's older than > GCC > 4.7 and is therefore not supported with Qt 5.7 and up. Upgrade. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Jan 3 21:01:43 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Jan 2018 18:01:43 -0200 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <5430322.KfG4hcZHa9@tjmaciei-mobl1> Message-ID: <2218432.kqOIL1ELSq@tjmaciei-mobl1> On Wednesday, 3 January 2018 17:53:40 -02 Toan Pham wrote: > Thiago, > > I am using gcc 4.8.5, but the compiler was optimized for pentium4 so all of > those vector instructions had to be disabled at build time. Ah, ok, provided "all those" imply "those that Pentium 4 did not support". > BTW, I got webengine to compile successfully with several patches to > libvpx. Now, I just ran into another brick wall with the errors attached > at the end of this email. > Here is my qt configure option: > > -prefix /opt/qt5.10.0 -no-separate-debug-info -system-zlib -system-libpng > -confirm-license -nomake examples -I /usr/X11/include -release > -webengine-webrtc -qt-libjpeg -no-sse2 -no-sse3 -no-sse3 -no-sse4.1 > -no-sse4.2 -no-avx -no-avx2 If you want to optimise for Pentium 4, you're going the wrong way about it. Please re-read the specs for your processor and disable ONLY the features it doesn't possess. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jan 3 21:25:19 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Jan 2018 18:25:19 -0200 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: <2218432.kqOIL1ELSq@tjmaciei-mobl1> References: <2218432.kqOIL1ELSq@tjmaciei-mobl1> Message-ID: <6606584.o0NAcNA3yp@tjmaciei-mobl1> On Wednesday, 3 January 2018 18:01:43 -02 Thiago Macieira wrote: > > -prefix /opt/qt5.10.0 -no-separate-debug-info -system-zlib -system-libpng > > -confirm-license -nomake examples -I /usr/X11/include -release > > -webengine-webrtc -qt-libjpeg -no-sse2 -no-sse3 -no-sse3 -no-sse4.1 > > -no-sse4.2 -no-avx -no-avx2 > > If you want to optimise for Pentium 4, you're going the wrong way about it. > Please re-read the specs for your processor and disable ONLY the features > it doesn't possess. In particular: -no-sse2. If you use that option, that means you're optimising for Pentium III and earlier, not Pentium 4. All Pentium 4 processors have SSE2. More importantly, SSE2 is *MANDATORY* for 64-bit builds. You may not turn it off. The errors you are getting are related specifically to this option. So are you sure you're building 32-bit? And when you said you built a Penitum4-optimised compiler, are you sure you didn't enable SSE2 out of the box? Please run this with your toolchain's compiler: g++ -dM -E -xc /dev/null | grep __SSE What does that print? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From igor.mironchik at gmail.com Thu Jan 4 07:27:06 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Thu, 4 Jan 2018 09:27:06 +0300 Subject: [Development] Project ERROR: Could not find feature future. In-Reply-To: <2329042.sbRi8KNLez@tjmaciei-mobl1> References: <2329042.sbRi8KNLez@tjmaciei-mobl1> Message-ID: Hi, On 03.01.2018 22:21, Thiago Macieira wrote: > On Wednesday, 3 January 2018 14:26:49 -02 Igor Mironchik wrote: >> Hello, >> >> What does it mean: Project ERROR: Could not find feature future. >> >> This is from qmake-ing corelib.pro in dev branch. > Are you sure you've finished configure in the qtbase top (or qt5.git)? I cloned clean full qt5 repo, init repo, qtbase checked out to dev branch, configure failed. ./configure -developer-build -opensource -nomake examples -nomake tests -prefix $PWD/qtbase -debug -confirm-license ... Checking for Socket CAN FD... yes Project ERROR: Unknown feature object qml-debug in expression 'features.qml-debug'. Maybe I need to checkout all projects to dev branch? What do I do wrong? Thank you. From tony.sarajarvi at qt.io Thu Jan 4 09:18:00 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Thu, 4 Jan 2018 08:18:00 +0000 Subject: [Development] CI down for a moment Message-ID: Hi all! We had situation where it seems like cachefilesd bugged and didn't do cache culling. Our hosts filled up and caches got messed up. After cleaning the corrupted images, we still had hosts having incorrect data in caches. So as a quick fix I'm redeploying all hosts now. It takes some time, but we get a clean slate to work on again. This was a last measure, but now I have an estimate of when the CI is back again. Before this I could only guess how to fix things and how long it would have taken. Hosts come back gradually, and the we'll be at 20% capacity in aprox 2-3 hours. Then 2-3 hours more to get another 20%. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Thu Jan 4 09:35:33 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 4 Jan 2018 09:35:33 +0100 Subject: [Development] Project ERROR: Could not find feature future. In-Reply-To: References: <2329042.sbRi8KNLez@tjmaciei-mobl1> Message-ID: <20180104083533.GA29616@ugly> On Thu, Jan 04, 2018 at 09:27:06AM +0300, Igor Mironchik wrote: > Maybe I need to checkout all projects to dev branch? > yes, you do. From thiago.macieira at intel.com Thu Jan 4 11:00:20 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 Jan 2018 08:00:20 -0200 Subject: [Development] Project ERROR: Could not find feature future. In-Reply-To: <20180104083533.GA29616@ugly> References: <20180104083533.GA29616@ugly> Message-ID: <3884529.ammRBLSnl4@tjmaciei-mobl1> On Thursday, 4 January 2018 06:35:33 -02 Oswald Buddenhagen wrote: > On Thu, Jan 04, 2018 at 09:27:06AM +0300, Igor Mironchik wrote: > > Maybe I need to checkout all projects to dev branch? > > yes, you do. All projects in the same branch. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From igor.mironchik at gmail.com Thu Jan 4 11:40:43 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Thu, 4 Jan 2018 13:40:43 +0300 Subject: [Development] Project ERROR: Could not find feature future. In-Reply-To: <3884529.ammRBLSnl4@tjmaciei-mobl1> References: <20180104083533.GA29616@ugly> <3884529.ammRBLSnl4@tjmaciei-mobl1> Message-ID: Hi, On 04.01.2018 13:00, Thiago Macieira wrote: > On Thursday, 4 January 2018 06:35:33 -02 Oswald Buddenhagen wrote: >> On Thu, Jan 04, 2018 at 09:27:06AM +0300, Igor Mironchik wrote: >>> Maybe I need to checkout all projects to dev branch? >> yes, you do. > All projects in the same branch. Yes, I did it, it helped. But I have one question: is it possible to switch branch "automatically" for qt5? I know about git submodule foreach --recursive but it will now help. Not all submodules have dev, 5.10 branches... And thank you guys. From thiago.macieira at intel.com Thu Jan 4 12:12:17 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 Jan 2018 09:12:17 -0200 Subject: [Development] Project ERROR: Could not find feature future. In-Reply-To: References: <3884529.ammRBLSnl4@tjmaciei-mobl1> Message-ID: <1838384.4dqP6Oab06@tjmaciei-mobl1> On Thursday, 4 January 2018 08:40:43 -02 Igor Mironchik wrote: > Hi, > > On 04.01.2018 13:00, Thiago Macieira wrote: > > On Thursday, 4 January 2018 06:35:33 -02 Oswald Buddenhagen wrote: > >> On Thu, Jan 04, 2018 at 09:27:06AM +0300, Igor Mironchik wrote: > >>> Maybe I need to checkout all projects to dev branch? > >> > >> yes, you do. > > > > All projects in the same branch. > > Yes, I did it, it helped. But I have one question: is it possible to > switch branch "automatically" for qt5? > > I know about git submodule foreach --recursive but it will now help. Not > all submodules have dev, 5.10 branches... This is the solution, with ignoring the errors in the modules that don't have those branches. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From igor.mironchik at gmail.com Thu Jan 4 12:19:23 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Thu, 4 Jan 2018 14:19:23 +0300 Subject: [Development] Project ERROR: Could not find feature future. In-Reply-To: <1838384.4dqP6Oab06@tjmaciei-mobl1> References: <3884529.ammRBLSnl4@tjmaciei-mobl1> <1838384.4dqP6Oab06@tjmaciei-mobl1> Message-ID: <2e5c3666-4e47-b017-502e-2d8f6ebbb791@gmail.com> >> Yes, I did it, it helped. But I have one question: is it possible to >> switch branch "automatically" for qt5? >> >> I know about git submodule foreach --recursive but it will now help. Not >> all submodules have dev, 5.10 branches... > This is the solution, with ignoring the errors in the modules that don't have > those branches. Yes, I did a mistake in the email... But it really can solve the problem: git submodule foreach --recursive "git checkout dev || true" :) Miss-understanding but the solution found. :) From andre.hartmann at iseg-hv.de Thu Jan 4 12:22:27 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Thu, 4 Jan 2018 12:22:27 +0100 Subject: [Development] Project ERROR: Could not find feature future. In-Reply-To: <1838384.4dqP6Oab06@tjmaciei-mobl1> References: <3884529.ammRBLSnl4@tjmaciei-mobl1> <1838384.4dqP6Oab06@tjmaciei-mobl1> Message-ID: <25a9da32-6ee7-7df2-e25d-9e1e9a76f58d@iseg-hv.de> Hi, Am 04.01.2018 um 12:12 schrieb Thiago Macieira: > On Thursday, 4 January 2018 08:40:43 -02 Igor Mironchik wrote: >> Hi, >> >> On 04.01.2018 13:00, Thiago Macieira wrote: >>> On Thursday, 4 January 2018 06:35:33 -02 Oswald Buddenhagen wrote: >>>> On Thu, Jan 04, 2018 at 09:27:06AM +0300, Igor Mironchik wrote: >>>>> Maybe I need to checkout all projects to dev branch? >>>> >>>> yes, you do. >>> >>> All projects in the same branch. >> >> Yes, I did it, it helped. But I have one question: is it possible to >> switch branch "automatically" for qt5? >> >> I know about git submodule foreach --recursive but it will now help. Not >> all submodules have dev, 5.10 branches... > > This is the solution, with ignoring the errors in the modules that don't have > those branches. Maybe its worth to mention that you don't need to build all submodules. Just build qtbase and the modules you want to work in. -- Andre From oswald.buddenhagen at qt.io Thu Jan 4 13:19:44 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 4 Jan 2018 13:19:44 +0100 Subject: [Development] Project ERROR: Could not find feature future. In-Reply-To: References: <20180104083533.GA29616@ugly> <3884529.ammRBLSnl4@tjmaciei-mobl1> Message-ID: <20180104121944.GH27418@troll08> On Thu, Jan 04, 2018 at 01:40:43PM +0300, Igor Mironchik wrote: > Yes, I did it, it helped. But I have one question: is it possible to > switch branch "automatically" for qt5? > yes, it is, as pointed out on https://wiki.qt.io/Building_Qt_5_from_Git init-repository --branch From kevin.kofler at chello.at Thu Jan 4 15:16:37 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 04 Jan 2018 15:16:37 +0100 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine References: <2218432.kqOIL1ELSq@tjmaciei-mobl1> <6606584.o0NAcNA3yp@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > In particular: -no-sse2. > > If you use that option, that means you're optimising for Pentium III and > earlier, not Pentium 4. All Pentium 4 processors have SSE2. > > More importantly, SSE2 is *MANDATORY* for 64-bit builds. You may not turn > it off. The errors you are getting are related specifically to this > option. So are you sure you're building 32-bit? In addition, QtWebEngine always requires SSE2 no matter how you configure Qt. Chromium stopped supporting machines without SSE2 a few years ago. There is a huge patch (from me) to allow building for non-SSE2 i686 machines in the Fedora qt5-qtwebengine package, but that patch is completely unsupported by upstream. Kevin Kofler From edward.welbourne at qt.io Thu Jan 4 15:51:26 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 4 Jan 2018 14:51:26 +0000 Subject: [Development] About the presence of /System/Library/Frameworks/Carbon.framework In-Reply-To: <3300826.BcPtKKvnmx@tjmaciei-mobl1> References: <1939068.kntlJOzske@bola> <479391513853254@web5j.yandex.ru>,<3300826.BcPtKKvnmx@tjmaciei-mobl1> Message-ID: René J.V. Bertin: >>> 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? On quinta-feira, 21 de dezembro de 2017 04:47:34 CST Konstantin Tokarev wrote: >> Check uname maybe? Thiago Macieira (21 December 2017 12:54) replied: > 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. Well, it's reasonable to conclude you're set up to be capable of compiling for an Apple system; as here, it's possible this may be for the sake of cross-compiling; but the fact of having the means to cross-compile for a particular target does not mean that every build done on this machine necessarily is a cross-compile for that target. It does sound like we're a little too enthusiastic about jumping to a conclusion here - is there a better way to decide what we're compiling for ? Surely we should ignore uname if configure has options that explicitly ask for cross-compilation; but it's a reasonable thing to consult otherwise, when auto-detecting in the absence of explicit instructions - in particular, more to be trusted than the existence of (possibly non-native) frameworks, Eddy. From annulen at yandex.ru Thu Jan 4 21:35:38 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 04 Jan 2018 23:35:38 +0300 Subject: [Development] About the presence of /System/Library/Frameworks/Carbon.framework In-Reply-To: References: <1939068.kntlJOzske@bola> <479391513853254@web5j.yandex.ru>, <3300826.BcPtKKvnmx@tjmaciei-mobl1> Message-ID: <1018811515098138@web26o.yandex.ru> 04.01.2018, 17:51, "Edward Welbourne" : > René J.V. Bertin: >>>>  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? > > On quinta-feira, 21 de dezembro de 2017 04:47:34 CST Konstantin Tokarev wrote: >>>  Check uname maybe? > > Thiago Macieira (21 December 2017 12:54) replied: >>  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. > > Well, it's reasonable to conclude you're set up to be capable of > compiling for an Apple system; as here, it's possible this may be for > the sake of cross-compiling; but the fact of having the means to > cross-compile for a particular target does not mean that every build > done on this machine necessarily is a cross-compile for that target. > > It does sound like we're a little too enthusiastic about jumping to a > conclusion here - is there a better way to decide what we're compiling > for ? Surely we should ignore uname if configure has options that > explicitly ask for cross-compilation; but it's a reasonable thing to > consult otherwise, when auto-detecting in the absence of explicit > instructions - in particular, more to be trusted than the existence of > (possibly non-native) frameworks, Note that in opening letter different question was asked, namely how to detect if script is running on Mac or not, presumably to avoid asking Linux users to install Xcode. > >         Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Thu Jan 4 23:48:26 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 Jan 2018 20:48:26 -0200 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <6606584.o0NAcNA3yp@tjmaciei-mobl1> Message-ID: <1937435.LFb4RFMcuQ@tjmaciei-mobl1> On Thursday, 4 January 2018 12:16:37 -02 Kevin Kofler wrote: > Thiago Macieira wrote: > > In particular: -no-sse2. > > > > If you use that option, that means you're optimising for Pentium III and > > earlier, not Pentium 4. All Pentium 4 processors have SSE2. > > > > More importantly, SSE2 is *MANDATORY* for 64-bit builds. You may not turn > > it off. The errors you are getting are related specifically to this > > option. So are you sure you're building 32-bit? > > In addition, QtWebEngine always requires SSE2 no matter how you configure > Qt. Chromium stopped supporting machines without SSE2 a few years ago. > > There is a huge patch (from me) to allow building for non-SSE2 i686 machines > in the Fedora qt5-qtwebengine package, but that patch is completely > unsupported by upstream. And, like I said, Pentium 4 supports SSE2. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chgans at gmail.com Thu Jan 4 23:52:40 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Fri, 5 Jan 2018 11:52:40 +1300 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <2218432.kqOIL1ELSq@tjmaciei-mobl1> <6606584.o0NAcNA3yp@tjmaciei-mobl1> Message-ID: On 5 January 2018 at 03:16, Kevin Kofler wrote: > Thiago Macieira wrote: >> In particular: -no-sse2. >> >> If you use that option, that means you're optimising for Pentium III and >> earlier, not Pentium 4. All Pentium 4 processors have SSE2. I was looking at LEDE (a fork/merge of OpenWRT) recently, and their 'i386' build actually target Pentium 4, which is i686++ See https://lede-project.org/docs/instructionset/i386_pentium4 I have been fighting with x86_32 build of Qt too, I never managed to build Qt in 32 bits on a 64 bits OS, I always ended up hacking badly the host distro (OpenSuse and Ubuntu). I'm now using 32bits OS in a docker container. You're not (and I'm not either) the first one to report problems with building Qt on x86_32 Linux recently. Linux32 is officially not supported any more, and I think it is a mistake. Claiming that nobody needs Linux-x86_32 nowadays is plainly wrong. And dropping opensource/commercial Linux-x86_32 support just before Qt-5.6 (LTS) was not a user/client friendly move either. >> >> More importantly, SSE2 is *MANDATORY* for 64-bit builds. You may not turn >> it off. The errors you are getting are related specifically to this >> option. So are you sure you're building 32-bit? > > In addition, QtWebEngine always requires SSE2 no matter how you configure > Qt. Chromium stopped supporting machines without SSE2 a few years ago. > > There is a huge patch (from me) to allow building for non-SSE2 i686 machines > in the Fedora qt5-qtwebengine package, but that patch is completely > unsupported by upstream. I might investigate Fedora 24, which ships Qt-5.6. Chris > > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Jan 5 00:22:37 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 Jan 2018 21:22:37 -0200 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: Message-ID: <4907025.ahMxWiquOz@tjmaciei-mobl1> On Thursday, 4 January 2018 20:52:40 -02 Christian Gagneraud wrote: > On 5 January 2018 at 03:16, Kevin Kofler wrote: > > Thiago Macieira wrote: > >> In particular: -no-sse2. > >> > >> If you use that option, that means you're optimising for Pentium III and > >> earlier, not Pentium 4. All Pentium 4 processors have SSE2. > > I was looking at LEDE (a fork/merge of OpenWRT) recently, and their > 'i386' build actually target Pentium 4, which is i686++ > See https://lede-project.org/docs/instructionset/i386_pentium4 I don't know what devices LEDE is targetting, but we can break down 32-bit x86 into four segments: 1) IA MCUs (Intel Quark™ line): these are 32-bit-only MMU-less systems, with RAM measured in kilobytes. This is not relevant for Qt or, for that matter, Linux. If you're interested, my colleagues support it with the Zephyr Project. 2) Atom line: these are modern, low-power devices meant for embedded use, The initial run was 32-bit, but all modern Atom are 64-bit and support SSE 4.2. That's also what the Android x86-64 ABI requires. 3) regular desktop, laptop and server processors: we can assume they are 64- bit, since that's over 10 years old now. The first 64-bit Intel Macs also had SSE 4.2 support and that was 2009. Cloud infra usually runs on top of Intel Xeons, the first version of which was based on the Nehalem or Westmere architecture (also SSE 4.2). I'm not that familiar with AMD offerings, but looking at GCC's source code shows all modern AMD products also have AVX or AVX2. Our minimum Windows version (7) had quite good 64-bit support too. Finally, the only feature that glibc's ld.so uses to search for different libraries in 64-bit is AVX2 (2013). 4) obsolete processors: anything that is over 10 years old. Still a target for Linux distributions. Obviously, my employer would like nothing better than we start targetting 2 and 3. Those billions of transistors you have in your processor for AVX should get used to improve performance, not just produce heat. > I have been fighting with x86_32 build of Qt too, I never managed to > build Qt in 32 bits on a 64 bits OS, I always ended up hacking badly > the host distro (OpenSuse and Ubuntu). I'm now using 32bits OS in a > docker container. I've never had a problem, but I confess I don't try to build all of Qt. I build all[*] of Qt with GCC and Clang on Linux, but that's 64-bit. The 32-bit build is only for qtbase, once every couple of months. For example, I still need to do the benchmarking for the new qHash function in 32-bit, which I find to be a poor use of my time so I haven't done yet. [*] not including qtwebengine. I've never built that. > You're not (and I'm not either) the first one to report problems with > building Qt on x86_32 Linux recently. > Linux32 is officially not supported any more, and I think it is a mistake. Yes, it is. Please report issues so we can fix them. > Claiming that nobody needs Linux-x86_32 nowadays is plainly wrong. Agreed. There are people who need it. Very few, but they exist. It's only a matter of priorities. See the listing above: 32-bit processors only either fall into the "out of scope" category (microcontrollers) or "obsolete". So please don't expect us to dedicate a lot of time to it. Supply patches. > And dropping opensource/commercial Linux-x86_32 support just before Qt-5.6 > (LTS) was not a user/client friendly move either. Since it wasn't dropped, the point is moot. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chgans at gmail.com Fri Jan 5 02:40:40 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Fri, 5 Jan 2018 14:40:40 +1300 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: <4907025.ahMxWiquOz@tjmaciei-mobl1> References: <4907025.ahMxWiquOz@tjmaciei-mobl1> Message-ID: On 5 January 2018 at 12:22, Thiago Macieira wrote: > On Thursday, 4 January 2018 20:52:40 -02 Christian Gagneraud wrote: >> On 5 January 2018 at 03:16, Kevin Kofler wrote: >> > Thiago Macieira wrote: >> >> In particular: -no-sse2. >> >> >> >> If you use that option, that means you're optimising for Pentium III and >> >> earlier, not Pentium 4. All Pentium 4 processors have SSE2. >> >> I was looking at LEDE (a fork/merge of OpenWRT) recently, and their >> 'i386' build actually target Pentium 4, which is i686++ >> See https://lede-project.org/docs/instructionset/i386_pentium4 > > I don't know what devices LEDE is targetting, but we can break down 32-bit x86 > into four segments: It's not just about what hardware you target, in my case, i cannot build the codebase in 64 bits, simply because the code is not 64-bits ready (mainly due to legacy old/complicated components): Not only the code base is full of 32 vs 64 issues, but it actually doesn't build at all, and fixing it is not an easy job and not a priority (yet). I wish too, i could target Linux-x86_64, but i cannot. This codebase currently builds for WINTEL32 and Linux/ARM32, it used to be built for a Geode or VIA proc, some time ago, with Qt-4.x And thinking about that, why is it a pain to maintain Linux-x86_32 when you have to maintain Linux-_32 and -*_32? >From http://doc.qt.io/qt-5/supported-platforms.html, Qt-5.10 supports the following 32 bits platforms: - Android-armv7 - WatchOS-armv7 - Windows-{7,8.1,10}-x86_32 - Windows-UWP-{x86_32,armv7} - Boot2Qt-{armv7,x86_32} - Qnx-{armv7,x86_32} Please note the Boot2Qt-x86_32, which is a weird case as it is an "Embedded Linux" for x86_32 (Yocto). The only reason for supporting "Embedded Linux" for x86_32 and not "Desktop Linux" for x86_32 is, I guess, CI workload. > Obviously, my employer would like nothing better than we start targetting 2 > and 3. Those billions of transistors you have in your processor for AVX should > get used to improve performance, not just produce heat. Neatpick: AVX itself doesn't require billions of transistors, the first intel proc to require more than a billion transistor are 4 and 6 cores i7. https://en.wikipedia.org/wiki/Transistor_count This slides are interesting as well, https://www.inf.ethz.ch/personal/markusp/teaching/263-2300-ETH-spring12/slides/class03.pdf. L2/L3 cache is what takes the most space. >> I have been fighting with x86_32 build of Qt too, I never managed to >> build Qt in 32 bits on a 64 bits OS, I always ended up hacking badly >> the host distro (OpenSuse and Ubuntu). I'm now using 32bits OS in a >> docker container. > > I've never had a problem, but I confess I don't try to build all of Qt. I > build all[*] of Qt with GCC and Clang on Linux, but that's 64-bit. The 32-bit > build is only for qtbase, once every couple of months. For example, I still > need to do the benchmarking for the new qHash function in 32-bit, which I find > to be a poor use of my time so I haven't done yet. > [*] not including qtwebengine. I've never built that. You told me so a few month ago, and I switched to OpenSuse since then, but i still had issues, and the only way to get around was to break the host distro (force-install some dev packages, 'ln -sf' SO here and there, ...) Please share your script if you have some. > >> You're not (and I'm not either) the first one to report problems with >> building Qt on x86_32 Linux recently. >> Linux32 is officially not supported any more, and I think it is a mistake. > > Yes, it is. Please report issues so we can fix them. I might do it once i'm back on my 32 bits build task. But the difficulty is to create a "good" ticket. If I do it right now, the issue would look like: "I followed https://wiki.qt.io/Building_Qt_5_from_Git and i cannot build Qt-5.6 for x86_32 on a "common" Linux distro (x86_32/64)" With all due respect to Wiki contributors, https://wiki.qt.io/Building_Qt_5_from_Git looks like a giant mess, with the usual 200 Linux distro specifics, outdated and unorganised information, ... >> Claiming that nobody needs Linux-x86_32 nowadays is plainly wrong. > > Agreed. There are people who need it. Very few, but they exist. What do you base your "very few" on? I would be interested to see the download stats of Qt-5.5 for Linux-32. >> And dropping opensource/commercial Linux-x86_32 support just before Qt-5.6 >> (LTS) was not a user/client friendly move either. > > Since it wasn't dropped, the point is moot. Linux-Desktop-x86_32 was dropped with Qt-5.6. The last Qt version to support it was Qt-5.5, and Qt-5.5 has now disappear from http://download.qt.io/official_releases/qt/ ... Or maybe we're not talking about the same thing. I'm not even sure what the Qt Company means by "Supported until Mar. 16, 2019" on http://doc.qt.io/qt-5.6/supported-platforms.html (that's Qt-5.6). What I'm sure of, is that i cannot download Qt-5.6 binaries for Linux-x86_32 (commercial or opensource). Chris From thiago.macieira at intel.com Fri Jan 5 03:11:37 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 05 Jan 2018 00:11:37 -0200 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <4907025.ahMxWiquOz@tjmaciei-mobl1> Message-ID: <5120988.Mb6HJglHXC@tjmaciei-mobl1> On Thursday, 4 January 2018 23:40:40 -02 Christian Gagneraud wrote: > It's not just about what hardware you target, in my case, i cannot > build the codebase in 64 bits, simply because the code is not 64-bits > ready (mainly due to legacy old/complicated components): Not only the > code base is full of 32 vs 64 issues, but it actually doesn't build at > all, and fixing it is not an easy job and not a priority (yet). And that's an understandable, if unfortunate, situation. You should keep that version working, even if it means keeping an old compiler you know works, until you can clean up. But don't upgrade Qt either: keep the old version that you know was working. You should also prepare disclaimers to your customers about security issues not being fixed. > I wish too, i could target Linux-x86_64, but i cannot. This codebase > currently builds for WINTEL32 and Linux/ARM32, it used to be built for > a Geode or VIA proc, some time ago, with Qt-4.x The fact that you mention Geode and VIA means it's *old*. > And thinking about that, why is it a pain to maintain Linux-x86_32 > when you have to maintain Linux-_32 and -*_32? > From http://doc.qt.io/qt-5/supported-platforms.html, Qt-5.10 supports > the following 32 bits platforms: > - Android-armv7 > - WatchOS-armv7 > - Windows-{7,8.1,10}-x86_32 > - Windows-UWP-{x86_32,armv7} > - Boot2Qt-{armv7,x86_32} > - Qnx-{armv7,x86_32} It's not. Like I said, it is supported and there are no known issues with it. That is, if you use compilers and Linux distributions of equivalent age as the Qt that you're compiling. A 10-year-old hacked compiler targetting a 10-year-old processor doesn't count. > Please note the Boot2Qt-x86_32, which is a weird case as it is an > "Embedded Linux" for x86_32 (Yocto). > The only reason for supporting "Embedded Linux" for x86_32 and not > "Desktop Linux" for x86_32 is, I guess, CI workload. Also beats me. Like I said in my previous email, there were some 32-bit only Atoms in the beginning, but all new offerings in the last 4 years have been 64-bit capable. There are considerable advantages in using 64-bit, and I would even need to see numbers to agree there's a code or data size increase. I also know TQtC has been pushing hard for the Automotive segment and I know ALL of those are 64-bit capable (almost all are Intel). > > Obviously, my employer would like nothing better than we start targetting > > 2 > > and 3. Those billions of transistors you have in your processor for AVX > > should get used to improve performance, not just produce heat. > > Neatpick: AVX itself doesn't require billions of transistors, the > first intel proc to require more than a billion transistor are 4 and 6 > cores i7. > https://en.wikipedia.org/wiki/Transistor_count Fair enough. The billions are usually due to expanded L3 caches, not the CPU itself. I was exaggerating. Still, AVX and AVX2 are considerable die size (don't know how much). > This slides are interesting as well, > https://www.inf.ethz.ch/personal/markusp/teaching/263-2300-ETH-spring12/slid > es/class03.pdf. L2/L3 cache is what takes the most space. Some even have an "L4" shared with or even dedicated to the GPU, which is another transistor hog. > > I've never had a problem, but I confess I don't try to build all of Qt. I > > build all[*] of Qt with GCC and Clang on Linux, but that's 64-bit. The > > 32-bit build is only for qtbase, once every couple of months. For > > example, I still need to do the benchmarking for the new qHash function > > in 32-bit, which I find to be a poor use of my time so I haven't done > > yet. > > [*] not including qtwebengine. I've never built that. > > You told me so a few month ago, and I switched to OpenSuse since then, > but i still had issues, and the only way to get around was to break > the host distro (force-install some dev packages, 'ln -sf' SO here and > there, ...) > Please share your script if you have some. Regular configure -platform linux-g++-32 && make. There's nothing special. > > Yes, it is. Please report issues so we can fix them. > > I might do it once i'm back on my 32 bits build task. > But the difficulty is to create a "good" ticket. If I do it right now, > the issue would look like: > "I followed https://wiki.qt.io/Building_Qt_5_from_Git and i cannot > build Qt-5.6 for x86_32 on a "common" Linux distro (x86_32/64)" Your first few will probably be "you did something wrong", so post here so we can help you properly set up. You may be missing tools and development packages. Once we find an actual issue, someone will ask you to report (or just fix it). > >> Claiming that nobody needs Linux-x86_32 nowadays is plainly wrong. > > > > Agreed. There are people who need it. Very few, but they exist. > > What do you base your "very few" on? > I would be interested to see the download stats of Qt-5.5 for Linux-32. While I'd be interested too, you'll have to remember that's a 3 year old release, with 3 more years of people switching to 64-bit. Anyway, I base my answer on my listing from before, that ALL Linux-capable x86 CPUs sold in the last 4 years are 64-bit capable. The ones that weren't, from 2012 (early Atoms), are so slow and consume so much more power today that I don't expect them to be used for most serious purposes, and definitely not for any new project. Those few that do still use it for any reason can build from source. > >> And dropping opensource/commercial Linux-x86_32 support just before > >> Qt-5.6 > >> (LTS) was not a user/client friendly move either. > > > > Since it wasn't dropped, the point is moot. > > Linux-Desktop-x86_32 was dropped with Qt-5.6. The last Qt version to > support it was Qt-5.5, and Qt-5.5 has now disappear from > http://download.qt.io/official_releases/qt/ ... You're mistaking support for creating binaries. We do support a lot more than we create binaries for. We have to balance the interest in that download with the effort required to build, test and store forever the binary. For Qt 5.6, we judged that the effort outweighed the benefit of creating Linux 32-bit binaries. > Or maybe we're not talking about the same thing. I'm not even sure > what the Qt Company means by "Supported until Mar. 16, 2019" on > http://doc.qt.io/qt-5.6/supported-platforms.html (that's Qt-5.6). > What I'm sure of, is that i cannot download Qt-5.6 binaries for > Linux-x86_32 (commercial or opensource). That's Qt 5.6's support lifetime. It's a Long Term Support release, so we'll keep adding patches and fixes to it until that date. That includes all compilers and platforms that were supported at the time of the release, however difficult it may get for us next year to build. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mitch.curtis at qt.io Fri Jan 5 15:06:58 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 5 Jan 2018 14:06:58 +0000 Subject: [Development] QQmlAbstractUrlInterceptor Message-ID: While looking into https://bugreports.qt.io/browse/QTBUG-65444, I noticed that QQmlAbstractUrlInterceptor is a public class with documentation that doesn't really explain how to use it. See my comment here: https://bugreports.qt.io/browse/QTBUG-65444?focusedCommentId=385687&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-385687 Here's an old mailing list thread I found about it: http://lists.qt-project.org/pipermail/development/2013-July/011914.html Why was a public class added that can seemingly only be used with private API? Why did it have to be made public? And why doesn't the documentation actually explain how to use it? From Simon.Hausmann at qt.io Fri Jan 5 15:10:34 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 5 Jan 2018 14:10:34 +0000 Subject: [Development] QQmlAbstractUrlInterceptor In-Reply-To: References: Message-ID: Hi, I don't know either to be honest, this was a long time ago it seems. Perhaps we should consider marking the class \internal, as its "setter" on QQmlEngine is \internal, too. The feature that is public and document and that uses QQmlAbstractUrlInterceptor under the hood is QQmlFileSelector. Simon ________________________________ From: Development on behalf of Mitch Curtis Sent: Friday, January 5, 2018 3:06:58 PM To: development at qt-project.org Subject: [Development] QQmlAbstractUrlInterceptor While looking into https://bugreports.qt.io/browse/QTBUG-65444, I noticed that QQmlAbstractUrlInterceptor is a public class with documentation that doesn't really explain how to use it. See my comment here: https://bugreports.qt.io/browse/QTBUG-65444?focusedCommentId=385687&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-385687 Here's an old mailing list thread I found about it: http://lists.qt-project.org/pipermail/development/2013-July/011914.html Why was a public class added that can seemingly only be used with private API? Why did it have to be made public? And why doesn't the documentation actually explain how to use it? _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at qt.io Fri Jan 5 15:17:59 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 5 Jan 2018 14:17:59 +0000 Subject: [Development] QQmlAbstractUrlInterceptor In-Reply-To: References: Message-ID: I would be for that, considering there doesn't seem to have been a clear reason for making it public in either the commit message or docs. From: Simon Hausmann Sent: Friday, 5 January 2018 3:11 PM To: Mitch Curtis ; development at qt-project.org Subject: Re: QQmlAbstractUrlInterceptor Hi, I don't know either to be honest, this was a long time ago it seems. Perhaps we should consider marking the class \internal, as its "setter" on QQmlEngine is \internal, too. The feature that is public and document and that uses QQmlAbstractUrlInterceptor under the hood is QQmlFileSelector. Simon ________________________________ From: Development > on behalf of Mitch Curtis > Sent: Friday, January 5, 2018 3:06:58 PM To: development at qt-project.org Subject: [Development] QQmlAbstractUrlInterceptor While looking into https://bugreports.qt.io/browse/QTBUG-65444, I noticed that QQmlAbstractUrlInterceptor is a public class with documentation that doesn't really explain how to use it. See my comment here: https://bugreports.qt.io/browse/QTBUG-65444?focusedCommentId=385687&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-385687 Here's an old mailing list thread I found about it: http://lists.qt-project.org/pipermail/development/2013-July/011914.html Why was a public class added that can seemingly only be used with private API? Why did it have to be made public? And why doesn't the documentation actually explain how to use it? _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at qt.io Fri Jan 5 15:27:03 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 5 Jan 2018 14:27:03 +0000 Subject: [Development] QQmlAbstractUrlInterceptor In-Reply-To: References: Message-ID: Andy just pointed me towards this: https://bugreports.qt.io/browse/QTBUG-56209 I guess making it public would work too, and might even be the better option if people are already using it (unofficially) anyway. Either way, both need to be public or private. From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Mitch Curtis Sent: Friday, 5 January 2018 3:18 PM To: Simon Hausmann ; development at qt-project.org Subject: Re: [Development] QQmlAbstractUrlInterceptor I would be for that, considering there doesn't seem to have been a clear reason for making it public in either the commit message or docs. From: Simon Hausmann Sent: Friday, 5 January 2018 3:11 PM To: Mitch Curtis >; development at qt-project.org Subject: Re: QQmlAbstractUrlInterceptor Hi, I don't know either to be honest, this was a long time ago it seems. Perhaps we should consider marking the class \internal, as its "setter" on QQmlEngine is \internal, too. The feature that is public and document and that uses QQmlAbstractUrlInterceptor under the hood is QQmlFileSelector. Simon ________________________________ From: Development > on behalf of Mitch Curtis > Sent: Friday, January 5, 2018 3:06:58 PM To: development at qt-project.org Subject: [Development] QQmlAbstractUrlInterceptor While looking into https://bugreports.qt.io/browse/QTBUG-65444, I noticed that QQmlAbstractUrlInterceptor is a public class with documentation that doesn't really explain how to use it. See my comment here: https://bugreports.qt.io/browse/QTBUG-65444?focusedCommentId=385687&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-385687 Here's an old mailing list thread I found about it: http://lists.qt-project.org/pipermail/development/2013-July/011914.html Why was a public class added that can seemingly only be used with private API? Why did it have to be made public? And why doesn't the documentation actually explain how to use it? _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Jan 5 19:43:32 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 05 Jan 2018 16:43:32 -0200 Subject: [Development] Deadline for papers for Embedded Linux Conference + OpenIoT Summit is Sunday Message-ID: <7520460.ktvHe6dD6B@tjmaciei-mobl1> Suggested topics: * Qt Lite for embedded devices * Qt usage in automotive embedded * Boot2Qt and how easy it is to create a full, embedded device * Creating rich UIs with QML for embedded systems * REST support in QtNetwork and QtWebSockets, QtWebChannel * Any of OPC-UA, CoAP and Mqtt support * Cloud connectivity? I'll be submitting two talks on CBOR: one for TinyCBOR in the ELC part and one for REST support using Qt CBOR classes in the IoT support. If you send me your draft by EOD Saturday, I'll send you my review back by Sunday mid-day. Please read the LF's paper guidelines. Link: https:///events.linuxfoundation.org/events/elc-openiot-north-america-2018/ program/cfp See LF's reminder attached. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- An embedded message was scrubbed... From: ELC + OpenIoT Summit Subject: 3 weeks to submit a talk to speak at ELC + OpenIoT Summit NA 2018 Date: Wed, 20 Dec 2017 18:49:12 -0600 Size: 36955 URL: From chgans at gmail.com Sat Jan 6 11:47:42 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Sat, 6 Jan 2018 23:47:42 +1300 Subject: [Development] [OT] Re: 32bit linux build of qt5.10.0 w/ webengine Message-ID: On 5 January 2018 at 15:11, Thiago Macieira wrote: > On Thursday, 4 January 2018 23:40:40 -02 Christian Gagneraud wrote: >> Neatpick: AVX itself doesn't require billions of transistors, the >> first intel proc to require more than a billion transistor are 4 and 6 >> cores i7. >> https://en.wikipedia.org/wiki/Transistor_count > > Fair enough. The billions are usually due to expanded L3 caches, not the CPU > itself. I was exaggerating. or L2, or L1... it all depends on size. Static RAM usually requires 4 transistors per bit, and dynamic RAM only one (on average) 1MB of cache => 4 * 1 * 8 * 1024 * 1024 = 33.5 millions transistors The more cores on a die, the more L3 cache you need... And nowadays, 50MB of L3 is not that crazy... This is certainly wrong (i'm not very aware of the latest technologies), but it should be a "fair" guesstimate. > Still, AVX and AVX2 are considerable die size (don't know how much). I've googled for half an hour to find this information and finally gave up. Since you work for Intel, maybe you could ask one of your colleague, that's an interesting bit of information. Since SSE and AVX are just sub-components of a specialised ALU/FPU, I wouldn't be surprised if they require less than a few thousand transistors each (they "just" implement specialised operations), and die size contribution is certainly less than 0.01 % (Wild guess again). Another noob question would be how much of them is actually hard-wired operation vs instruction implemented via ROM microcode. Chris From chgans at gmail.com Sat Jan 6 12:21:35 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Sun, 7 Jan 2018 00:21:35 +1300 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: <5120988.Mb6HJglHXC@tjmaciei-mobl1> References: <4907025.ahMxWiquOz@tjmaciei-mobl1> <5120988.Mb6HJglHXC@tjmaciei-mobl1> Message-ID: On 5 January 2018 at 15:11, Thiago Macieira wrote: >> I wish too, i could target Linux-x86_64, but i cannot. This codebase >> currently builds for WINTEL32 and Linux/ARM32, it used to be built for >> a Geode or VIA proc, some time ago, with Qt-4.x > > The fact that you mention Geode and VIA means it's *old*. Yes parts of the code base are verrrrrrrrrrrry old (VIA/Geode is just ghost code), certainly older than Qt itself... But that was not my point: I don't have a HW problem, I have a SW problem. I cannot link against Qt-x86_64 b/c i cannot build my codebase for x86_64. I will run Qt/32bits on a 64 bits machine. This is my (sad) life, period. >> > I've never had a problem, but I confess I don't try to build all of Qt. I >> > build all[*] of Qt with GCC and Clang on Linux, but that's 64-bit. The >> > 32-bit build is only for qtbase, once every couple of months. For >> > example, I still need to do the benchmarking for the new qHash function >> > in 32-bit, which I find to be a poor use of my time so I haven't done >> > yet. >> > [*] not including qtwebengine. I've never built that. >> >> You told me so a few month ago, and I switched to OpenSuse since then, >> but i still had issues, and the only way to get around was to break >> the host distro (force-install some dev packages, 'ln -sf' SO here and >> there, ...) >> Please share your script if you have some. > > Regular configure -platform linux-g++-32 && make. There's nothing special. Well, thanks for the tip! The main issue is dependencies, the best document I found is an ICS blog post: https://www.ics.com/blog/how-compile-qt-source-code-linux But that covers only 32bits build on 32bits host or 64bits build on 64 bits host. When I asked my question a few month ago, it was all about how to install all the 32 bits (dev) packages on a 64 bits Linux machine without having to resort to "dirty hacks", and so far i've been unlucky, and nobody was able to give me any hints (not blaming anyone here) So may I rephrase my question? Do you have the magic list for apt/zypper that would allow to build Qt-5.6/32bits (or Qt-5.9) on a 64bits Linux machine? I don't care about Redhat vs Suse vs Debian vs ... I just need to generate a 32 bits archive of Qt that can be used on a 64 bits Linux machine. >> Or maybe we're not talking about the same thing. I'm not even sure >> what the Qt Company means by "Supported until Mar. 16, 2019" on >> http://doc.qt.io/qt-5.6/supported-platforms.html (that's Qt-5.6). >> What I'm sure of, is that i cannot download Qt-5.6 binaries for >> Linux-x86_32 (commercial or opensource). > > That's Qt 5.6's support lifetime. It's a Long Term Support release, so we'll > keep adding patches and fixes to it until that date. That includes all > compilers and platforms that were supported at the time of the release, > however difficult it may get for us next year to build. Just a wee reminder that "support" doesn't mean "full support". Remember how we ended up on the gcc (or binutils?) bug board because the QThread test suite was failing? For me, it's quite simple: No (opensource/commercial) Qt CI = No (opensource/commercial) Qt binaries = No (opensource/commercial) support. If you don't build and test on a regular basis, it can break at any moment without anyone noticing (and it did happened at least once) Chris PS: In case you think I'm ranting for free here, i would like to say (again) that I think Qt is a great piece of (opensource/commercial) SW, and big thumb up to anyone behind this, The Qt Project, The Qt Company, Intel, ICS, KDAB, KDE, ... and everyone else, individual or corporate. From thiago.macieira at intel.com Sat Jan 6 15:27:31 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 06 Jan 2018 12:27:31 -0200 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <5120988.Mb6HJglHXC@tjmaciei-mobl1> Message-ID: <5244576.1dG1z4Tzuh@tjmaciei-mobl1> On Saturday, 6 January 2018 09:21:35 -02 Christian Gagneraud wrote: > > Regular configure -platform linux-g++-32 && make. There's nothing special. > > Well, thanks for the tip! To be clear, this is my config.opt (newlines replaced by spaces). I have other options, but nothing special: -opensource -confirm-license -developer-build -system-libjpeg -system-libpng -system-sqlite -reduce-relocations -xcb -pch -dbus-runtime -qtlibinfix .32 -nomake tests -nomake examples -platform linux-g++-32-optimised -qtnamespace QtI386 -release As you can see, this is also my namespace-testing build. As for linux-g++-32- optimised, it's basically adding -march=native -mno-rdrnd to QMAKE_CFLAGS. > The main issue is dependencies, the best document I found is an ICS blog > post: https://www.ics.com/blog/how-compile-qt-source-code-linux > > But that covers only 32bits build on 32bits host or 64bits build on 64 > bits host. $ rpm -qa --qf "%{NAME}\\n" *-devel-32bit libstdc++-devel-32bit libICE-devel-32bit libxkbcommon-devel-32bit libjpeg62-devel-32bit xcb-util-wm-devel-32bit libX11-devel-32bit libSM-devel-32bit libXext-devel-32bit libxcb-devel-32bit libpng16-devel-32bit xcb-util-image-devel-32bit dbus-1-devel-32bit glibc-devel-32bit xcb-util-keysyms-devel-32bit libXi-devel-32bit > When I asked my question a few month ago, it was all about how to > install all the 32 bits (dev) packages on a 64 bits Linux machine > without having to resort to "dirty hacks", and so far i've been > unlucky, and nobody was able to give me any hints (not blaming anyone > here) > > So may I rephrase my question? > Do you have the magic list for apt/zypper that would allow to build > Qt-5.6/32bits (or Qt-5.9) on a 64bits Linux machine? Try installing my listing above. It should be a good start. It's probably not complete: you may need some more 32-bit tools that aren't *-devel-32bit and you need some 64-bit tools too. > >> Or maybe we're not talking about the same thing. I'm not even sure > >> what the Qt Company means by "Supported until Mar. 16, 2019" on > >> http://doc.qt.io/qt-5.6/supported-platforms.html (that's Qt-5.6). > >> What I'm sure of, is that i cannot download Qt-5.6 binaries for > >> Linux-x86_32 (commercial or opensource). > > > > That's Qt 5.6's support lifetime. It's a Long Term Support release, so > > we'll keep adding patches and fixes to it until that date. That includes > > all compilers and platforms that were supported at the time of the > > release, however difficult it may get for us next year to build. > > Just a wee reminder that "support" doesn't mean "full support". > Remember how we ended up on the gcc (or binutils?) bug board because > the QThread test suite was failing? Right, there are levels. There are platform combinations that are tested by the main CI; there are others that are tested only by the qt5.git CI. All of those are confirmed to be compiling and working at any release. Then there are those we are pretty confident on, but don't always check. Here's the link for the last qt5 5.9 integration: https://testresults.qt.io/coin/integration/qt/qt5/tasks/1515209498 As you can see, there are a couple of 32-bit builds: * Android 32-bit x86 * Integrity 32-bit ARM * Linux 32-bit ARM * QNX 32-bit ARM and x86 * Windows 32-bit x86 (MinGW and MSVC) So even though a 32-bit x86 build for regular Linux is missing, we should be pretty confident it works. It would only be failing if we had some x86- specific Linux-specific (non-Android) code and I don't think we do. We have x86-specific code, but it's cross-OS and/or 64-bit capable too: the only thing I can think of that comes closest is the early CPUID detection, since all 64-bit CPUs have CPUID and the assembly is compiler dependent, but even then it's code we don't need to modify and it does get compiled on for both Android and MinGW. > For me, it's quite simple: > No (opensource/commercial) Qt CI = No (opensource/commercial) Qt > binaries = No (opensource/commercial) support. No CI, see above. No binaries, build from sources. No support, sorry, I can't comment. > If you don't build and test on a regular basis, it can break at any > moment without anyone noticing (and it did happened at least once) You're right, but given all the other permutations, we're very likely covered at a good 99% certainty. > PS: In case you think I'm ranting for free here, i would like to say > (again) that I think Qt is a great piece of (opensource/commercial) > SW, and big thumb up to anyone behind this, The Qt Project, The Qt > Company, Intel, ICS, KDAB, KDE, ... and everyone else, individual or > corporate. We're having a constructive conversation, don't worry. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chgans at gmail.com Sun Jan 7 01:15:50 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Sun, 7 Jan 2018 13:15:50 +1300 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: <5244576.1dG1z4Tzuh@tjmaciei-mobl1> References: <5120988.Mb6HJglHXC@tjmaciei-mobl1> <5244576.1dG1z4Tzuh@tjmaciei-mobl1> Message-ID: Hi Thiago, Thanks for the details, i'll switch to qt-interest. I've made progress but still have a weird package conflict for QtWebEngine. Chris On 7 January 2018 at 03:27, Thiago Macieira wrote: > On Saturday, 6 January 2018 09:21:35 -02 Christian Gagneraud wrote: >> > Regular configure -platform linux-g++-32 && make. There's nothing special. >> >> Well, thanks for the tip! > > To be clear, this is my config.opt (newlines replaced by spaces). I have other > options, but nothing special: > > -opensource -confirm-license -developer-build -system-libjpeg -system-libpng > -system-sqlite -reduce-relocations -xcb -pch -dbus-runtime -qtlibinfix .32 > -nomake tests -nomake examples -platform linux-g++-32-optimised > -qtnamespace QtI386 -release > > As you can see, this is also my namespace-testing build. As for linux-g++-32- > optimised, it's basically adding -march=native -mno-rdrnd to QMAKE_CFLAGS. > >> The main issue is dependencies, the best document I found is an ICS blog >> post: https://www.ics.com/blog/how-compile-qt-source-code-linux >> >> But that covers only 32bits build on 32bits host or 64bits build on 64 >> bits host. > > $ rpm -qa --qf "%{NAME}\\n" *-devel-32bit > libstdc++-devel-32bit > libICE-devel-32bit > libxkbcommon-devel-32bit > libjpeg62-devel-32bit > xcb-util-wm-devel-32bit > libX11-devel-32bit > libSM-devel-32bit > libXext-devel-32bit > libxcb-devel-32bit > libpng16-devel-32bit > xcb-util-image-devel-32bit > dbus-1-devel-32bit > glibc-devel-32bit > xcb-util-keysyms-devel-32bit > libXi-devel-32bit > >> When I asked my question a few month ago, it was all about how to >> install all the 32 bits (dev) packages on a 64 bits Linux machine >> without having to resort to "dirty hacks", and so far i've been >> unlucky, and nobody was able to give me any hints (not blaming anyone >> here) >> >> So may I rephrase my question? >> Do you have the magic list for apt/zypper that would allow to build >> Qt-5.6/32bits (or Qt-5.9) on a 64bits Linux machine? > > Try installing my listing above. It should be a good start. > > It's probably not complete: you may need some more 32-bit tools that aren't > *-devel-32bit and you need some 64-bit tools too. > >> >> Or maybe we're not talking about the same thing. I'm not even sure >> >> what the Qt Company means by "Supported until Mar. 16, 2019" on >> >> http://doc.qt.io/qt-5.6/supported-platforms.html (that's Qt-5.6). >> >> What I'm sure of, is that i cannot download Qt-5.6 binaries for >> >> Linux-x86_32 (commercial or opensource). >> > >> > That's Qt 5.6's support lifetime. It's a Long Term Support release, so >> > we'll keep adding patches and fixes to it until that date. That includes >> > all compilers and platforms that were supported at the time of the >> > release, however difficult it may get for us next year to build. >> >> Just a wee reminder that "support" doesn't mean "full support". >> Remember how we ended up on the gcc (or binutils?) bug board because >> the QThread test suite was failing? > > Right, there are levels. There are platform combinations that are tested by > the main CI; there are others that are tested only by the qt5.git CI. All of > those are confirmed to be compiling and working at any release. Then there are > those we are pretty confident on, but don't always check. > > Here's the link for the last qt5 5.9 integration: > https://testresults.qt.io/coin/integration/qt/qt5/tasks/1515209498 > > As you can see, there are a couple of 32-bit builds: > * Android 32-bit x86 > * Integrity 32-bit ARM > * Linux 32-bit ARM > * QNX 32-bit ARM and x86 > * Windows 32-bit x86 (MinGW and MSVC) > > So even though a 32-bit x86 build for regular Linux is missing, we should be > pretty confident it works. It would only be failing if we had some x86- > specific Linux-specific (non-Android) code and I don't think we do. > > We have x86-specific code, but it's cross-OS and/or 64-bit capable too: the > only thing I can think of that comes closest is the early CPUID detection, > since all 64-bit CPUs have CPUID and the assembly is compiler dependent, but > even then it's code we don't need to modify and it does get compiled on for > both Android and MinGW. > >> For me, it's quite simple: >> No (opensource/commercial) Qt CI = No (opensource/commercial) Qt >> binaries = No (opensource/commercial) support. > > No CI, see above. > No binaries, build from sources. > No support, sorry, I can't comment. > >> If you don't build and test on a regular basis, it can break at any >> moment without anyone noticing (and it did happened at least once) > > You're right, but given all the other permutations, we're very likely covered > at a good 99% certainty. > >> PS: In case you think I'm ranting for free here, i would like to say >> (again) that I think Qt is a great piece of (opensource/commercial) >> SW, and big thumb up to anyone behind this, The Qt Project, The Qt >> Company, Intel, ICS, KDAB, KDE, ... and everyone else, individual or >> corporate. > > We're having a constructive conversation, don't worry. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kevin.kofler at chello.at Sun Jan 7 04:43:00 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 07 Jan 2018 04:43 +0100 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine References: <4907025.ahMxWiquOz@tjmaciei-mobl1> <5120988.Mb6HJglHXC@tjmaciei-mobl1> Message-ID: Christian Gagneraud wrote: > When I asked my question a few month ago, it was all about how to > install all the 32 bits (dev) packages on a 64 bits Linux machine > without having to resort to "dirty hacks", and so far i've been > unlucky, and nobody was able to give me any hints (not blaming anyone > here) > > So may I rephrase my question? > Do you have the magic list for apt/zypper that would allow to build > Qt-5.6/32bits (or Qt-5.9) on a 64bits Linux machine? > I don't care about Redhat vs Suse vs Debian vs ... I just need to > generate a 32 bits archive of Qt that can be used on a 64 bits Linux > machine. One possibility that always works is to just set up a 32-bit chroot on your 64-bit system, where everything is 32-bit: libraries, compiler, etc. On Fedora, the "mock" tool can produce such a chroot, other distros have other comparable tools. Otherwise, how to install 32-bit libraries on a 64-bit distribution depends on the distribution: * in multilib distributions such as Fedora, you install the 32-bit -devel package that is copied by the distribution from the 32-bit distribution into the 64-bit repositories. In Fedora, this is done by specifying, e.g., "glibc-devel.i686" instead of just "glibc-devel" on the dnf command line. * non-multilib distributions typically have special packages with names such as glibc-devel-32bit. In any case, the exact naming is distro-dependent. Kevin Kofler From igor.mironchik at gmail.com Sun Jan 7 06:04:46 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Sun, 7 Jan 2018 08:04:46 +0300 Subject: [Development] Abandon changes set on Gerrit Message-ID: Hello, I see a button "Abandon Change" under the last patch set. Does this button abandon all changes set or only the last patch set? I want to abandon whole changes set. Thank you. From szehowe.koh at gmail.com Sun Jan 7 06:50:09 2018 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Sun, 7 Jan 2018 13:50:09 +0800 Subject: [Development] Abandon changes set on Gerrit In-Reply-To: References: Message-ID: On 7 January 2018 at 13:04, Igor Mironchik wrote: > Hello, > > I see a button "Abandon Change" under the last patch set. Does this button > abandon all changes set or only the last patch set? > > I want to abandon whole changes set. > > Thank you. That button abandons all the patch sets with that Change-Id. Don't worry, if you make a mistake with that button, you can still un-abandon it. Regards, Sze-Howe From thiago.macieira at intel.com Sun Jan 7 13:47:27 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 07 Jan 2018 06:47:27 -0600 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: Message-ID: <3409578.9l8QgSSR9T@tjmaciei-mobl1> On Saturday, 6 January 2018 21:43:00 CST Kevin Kofler wrote: > One possibility that always works is to just set up a 32-bit chroot on your > 64-bit system, where everything is 32-bit: libraries, compiler, etc. On > Fedora, the "mock" tool can produce such a chroot, other distros have other > comparable tools. You can find instructions for several distros in the systemd-nspawn man page. You don't need to use it for starting your chroot, but you can too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Mon Jan 8 06:10:18 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 8 Jan 2018 05:10:18 +0000 Subject: [Development] Changes files for Qt 5.9.4 Message-ID: Initial ones are here: https://codereview.qt-project.org/#/q/branch:5.9.4+message:%22Add+changes+file+for+Qt+5.9.4%22,n,z Please finalize as soon as possible; we are trying to get release out ~Mid January br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Mon Jan 8 09:13:48 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 8 Jan 2018 08:13:48 +0000 Subject: [Development] Dropping of MSVC 2013 In-Reply-To: <2059439.AcAk3oIIbm@tjmaciei-mobl1> References: <2827905.1UXfmysL1p@tjmaciei-mobl1> <2059439.AcAk3oIIbm@tjmaciei-mobl1> Message-ID: FYI As per https://codereview.qt-project.org/#/c/205305/ MSVC2013 is no longer in the CI. -- Alex From lars.knoll at qt.io Mon Jan 8 09:21:00 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 8 Jan 2018 08:21:00 +0000 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: <5244576.1dG1z4Tzuh@tjmaciei-mobl1> References: <5120988.Mb6HJglHXC@tjmaciei-mobl1> <5244576.1dG1z4Tzuh@tjmaciei-mobl1> Message-ID: <541394F3-306E-4B79-85F1-6C83A966C53B@qt.io> > >> For me, it's quite simple: >> No (opensource/commercial) Qt CI = No (opensource/commercial) Qt >> binaries = No (opensource/commercial) support. > > No CI, see above. > No binaries, build from sources. > No support, sorry, I can't comment. Just a quick comment from TQtC’s perspective on this: We do commercially support more platforms than we create binaries for. Linux/32bit is certainly one of those. But as Thiago pointed out, those platforms are not always tested quite as well (unfortunately we can’t possibly test all combinations of OS/CPU architecture/distribution in our CI). Cheers, Lars > >> If you don't build and test on a regular basis, it can break at any >> moment without anyone noticing (and it did happened at least once) > > You're right, but given all the other permutations, we're very likely covered > at a good 99% certainty. > >> PS: In case you think I'm ranting for free here, i would like to say >> (again) that I think Qt is a great piece of (opensource/commercial) >> SW, and big thumb up to anyone behind this, The Qt Project, The Qt >> Company, Intel, ICS, KDAB, KDE, ... and everyone else, individual or >> corporate. > > We're having a constructive conversation, don't worry. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From rjvbertin at gmail.com Mon Jan 8 11:17:36 2018 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 08 Jan 2018 11:17:36 +0100 Subject: [Development] About the presence of /System/Library/Frameworks/Carbon.framework References: <1939068.kntlJOzske@bola> <479391513853254@web5j.yandex.ru> <3300826.BcPtKKvnmx@tjmaciei-mobl1> <1018811515098138@web26o.yandex.ru> Message-ID: <1563434.6Mq9d6Ykb3@patux.local> Konstantin Tokarev wrote: >> It does sound like we're a little too enthusiastic about jumping to a >> conclusion here - is there a better way to decide what we're compiling >> for ? Surely we should ignore uname if configure has options that >> explicitly ask for cross-compilation; but it's a reasonable thing to >> consult otherwise, when auto-detecting in the absence of explicit >> instructions - in particular, more to be trusted than the existence of >> (possibly non-native) frameworks, > > Note that in opening letter different question was asked, namely how to > detect if script is running on Mac or not, presumably to avoid asking Linux > users to install Xcode. I think Edward is raising the same question, but yes, the reason I raised my question was that I was prompted to install Xcode AND that that was all the script would do. The former is ... pittoresque, the latter is more annoying. A combination of tests might be the way to go. I noticed the same check for Carbon.framework in the MacPorts sources (also to distinguish PureDarwin). But in their case they check the result from `tcl_platform(os)` first. If memory serves me well that variable is initialised from uname. I.e. something like if [ $UNAME_SYSTEM = Darwin -a -d /System/Library/Frameworks/Carbon.framework ]; then BUILD_ON_MAC=yes fi The only situation in which this test could fail validly would be on PureDarwin or similar OS ("true and false"). That's exactly what is required here, no? Alternatively, there's `sysctl hw.model` which can probably be used as the unique test. And of course there's the possibility to add a way to force the script to continue in an unforeseen situation (but that seems more work). R. From oswald.buddenhagen at qt.io Mon Jan 8 14:40:15 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 8 Jan 2018 14:40:15 +0100 Subject: [Development] [FYI] the new way to retarget gerrit changes Message-ID: <20180108134015.GA23646@troll08> On Mon, Sep 12, 2016 at 02:39:57PM +0300, Orgad Shaneh wrote: > Either extend the sanity bot, or create a new bot, which listens on > gerrit's event stream. > If the change's owner (or an approver?) posts a comment reading "Please > retarget ", run your script on the server side. You need some > sanity test that ensures this branch exists etc... > ... which he implemented, and it's deployed now. for simplicity, only the change owner may issue the command. for other cases, you still need to go through an admin. the same is advisable for batch requests, but do as you wish. the regex is /^(?:gerrit-)?bot:\h*(?:please\h+)?move\h+(?:back\h+)?to\h+(?:branch\h+)?([\w.]*\w)\b/im which boils down to "bot: move to " at the start of any line of a gerrit cover message. From Shawn.Rutledge at qt.io Mon Jan 8 14:47:08 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 8 Jan 2018 13:47:08 +0000 Subject: [Development] [FYI] the new way to retarget gerrit changes In-Reply-To: <20180108134015.GA23646@troll08> References: <20180108134015.GA23646@troll08> Message-ID: <6178D37F-8A31-4629-85D8-32782EF2BF41@qt.io> > On 8 Jan 2018, at 14:40, Oswald Buddenhagen wrote: > > On Mon, Sep 12, 2016 at 02:39:57PM +0300, Orgad Shaneh wrote: >> Either extend the sanity bot, or create a new bot, which listens on >> gerrit's event stream. >> If the change's owner (or an approver?) posts a comment reading "Please >> retarget ", run your script on the server side. You need some >> sanity test that ensures this branch exists etc... >> > ... which he implemented, and it's deployed now. > > for simplicity, only the change owner may issue the command. for other > cases, you still need to go through an admin. the same is advisable for > batch requests, but do as you wish. > > the regex is > > /^(?:gerrit-)?bot:\h*(?:please\h+)?move\h+(?:back\h+)?to\h+(?:branch\h+)?([\w.]*\w)\b/im > > which boils down to "bot: move to " at the start of any line of > a gerrit cover message. It seems to work too. Awesome. From annulen at yandex.ru Mon Jan 8 14:48:44 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 08 Jan 2018 16:48:44 +0300 Subject: [Development] [Qt-creator] [FYI] the new way to retarget gerrit changes In-Reply-To: <20180108134015.GA23646@troll08> References: <20180108134015.GA23646@troll08> Message-ID: <2259071515419324@web15g.yandex.ru> 08.01.2018, 16:40, "Oswald Buddenhagen" : > On Mon, Sep 12, 2016 at 02:39:57PM +0300, Orgad Shaneh wrote: >>     Either extend the sanity bot, or create a new bot, which listens on >>     gerrit's event stream. >>     If the change's owner (or an approver?) posts a comment reading "Please >>     retarget ", run your script on the server side. You need some >>     sanity test that ensures this branch exists etc... > > ... which he implemented, and it's deployed now. > > for simplicity, only the change owner may issue the command. for other > cases, you still need to go through an admin. the same is advisable for > batch requests, but do as you wish. I think batch requests should be automated by adding comments via Gerrit's API (to minimize your distractions) > > the regex is > >   /^(?:gerrit-)?bot:\h*(?:please\h+)?move\h+(?:back\h+)?to\h+(?:branch\h+)?([\w.]*\w)\b/im > > which boils down to "bot: move to " at the start of any line of > a gerrit cover message. Oh, "please" keyword :) > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator -- Regards, Konstantin From orgads at gmail.com Mon Jan 8 14:51:13 2018 From: orgads at gmail.com (Orgad Shaneh) Date: Mon, 8 Jan 2018 15:51:13 +0200 Subject: [Development] [Qt-creator] [FYI] the new way to retarget gerrit changes In-Reply-To: <2259071515419324@web15g.yandex.ru> References: <20180108134015.GA23646@troll08> <2259071515419324@web15g.yandex.ru> Message-ID: On Mon, Jan 8, 2018 at 3:48 PM, Konstantin Tokarev wrote: > > > 08.01.2018, 16:40, "Oswald Buddenhagen" : > > On Mon, Sep 12, 2016 at 02:39:57PM +0300, Orgad Shaneh wrote: > >> Either extend the sanity bot, or create a new bot, which listens on > >> gerrit's event stream. > >> If the change's owner (or an approver?) posts a comment reading > "Please > >> retarget ", run your script on the server side. You need > some > >> sanity test that ensures this branch exists etc... > > > > ... which he implemented, and it's deployed now. > > > > for simplicity, only the change owner may issue the command. for other > > cases, you still need to go through an admin. the same is advisable for > > batch requests, but do as you wish. > > I think batch requests should be automated by adding comments via Gerrit's > API > (to minimize your distractions) > That's exactly what was done. Or did I misread your comment? All you need to do is add a comment in gerrit saying: "bot: move to 5.10" and you're done. - Orgad -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Mon Jan 8 15:00:36 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 08 Jan 2018 17:00:36 +0300 Subject: [Development] [Qt-creator] [FYI] the new way to retarget gerrit changes In-Reply-To: References: <20180108134015.GA23646@troll08> <2259071515419324@web15g.yandex.ru> Message-ID: <703151515420036@web20o.yandex.ru> 08.01.2018, 16:51, "Orgad Shaneh" : > On Mon, Jan 8, 2018 at 3:48 PM, Konstantin Tokarev wrote: > >> 08.01.2018, 16:40, "Oswald Buddenhagen" : >>> On Mon, Sep 12, 2016 at 02:39:57PM +0300, Orgad Shaneh wrote: >>>>     Either extend the sanity bot, or create a new bot, which listens on >>>>     gerrit's event stream. >>>>     If the change's owner (or an approver?) posts a comment reading "Please >>>>     retarget ", run your script on the server side. You need some >>>>     sanity test that ensures this branch exists etc... >>> >>> ... which he implemented, and it's deployed now. >>> >>> for simplicity, only the change owner may issue the command. for other >>> cases, you still need to go through an admin. the same is advisable for >>> batch requests, but do as you wish. >> >> I think batch requests should be automated by adding comments via Gerrit's API >> (to minimize your distractions) > > That's exactly what was done. Or did I misread your comment? > > All you need to do is add a comment in gerrit saying: "bot: move to 5.10" and you're done. I mean, there can be additional script on client side, to add this comment to several changes (if I usderstood "batch request" correctly) > > - Orgad --  Regards, Konstantin From igor.mironchik at gmail.com Tue Jan 9 09:09:25 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Tue, 9 Jan 2018 11:09:25 +0300 Subject: [Development] [FYI] the new way to retarget gerrit changes In-Reply-To: <20180108134015.GA23646@troll08> References: <20180108134015.GA23646@troll08> Message-ID: <0ab97c04-994c-d79c-3e4c-44a443583510@gmail.com> Hello, > /^(?:gerrit-)?bot:\h*(?:please\h+)?move\h+(?:back\h+)?to\h+(?:branch\h+)?([\w.]*\w)\b/im > > which boils down to "bot: move to " at the start of any line of > a gerrit cover message. What is gerrit cover message? Is it a comment message on gerrit CR web page? Thank you. From joerg.bornemann at qt.io Tue Jan 9 09:47:02 2018 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Tue, 9 Jan 2018 09:47:02 +0100 Subject: [Development] [FYI] the new way to retarget gerrit changes In-Reply-To: <0ab97c04-994c-d79c-3e4c-44a443583510@gmail.com> References: <20180108134015.GA23646@troll08> <0ab97c04-994c-d79c-3e4c-44a443583510@gmail.com> Message-ID: <536c4175-48bd-7847-0941-d1aea6fedf98@qt.io> On 01/09/2018 09:09 AM, Igor Mironchik wrote: > What is gerrit cover message? Is it a comment message on gerrit CR web > page? Yes, that's just a comment in gerrit's web interface. The label above the text edit says "cover message". Joerg From annulen at yandex.ru Tue Jan 9 11:27:10 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 09 Jan 2018 13:27:10 +0300 Subject: [Development] Coin, Boot2Qt, and OE_QMAKE_PATH_HOST_BINS variable Message-ID: <1674861515493630@web5g.yandex.ru> Hello, I've tried to enable cross-compilation in Coin for QtWebKit 5.212 to improve platform coverage in each build, however I've faced following problem. Our Linux cross-compilation platform is Boot2Qt which is based on meta-qt5 Yocto layer. QtWebKit uses CMake internally, and Qt cmake config files on this platform rely on environment variable OE_QMAKE_PATH_HOST_BINS (see patch[1]). However, qmake-based builds seem to work fine without this variable. I suppose that patch[1] is wrong. Can we revert it in Yocto images used in Coin? [1] https://github.com/meta-qt5/meta-qt5/blob/268429962056a12e0e899612dafb433c257af5cf/recipes-qt/qt5/qtbase/0006-Pretend-Qt5-wasn-t-found-if-OE_QMAKE_PATH_EXTERNAL_H.patch You can see that this patch avtually checks OE_QMAKE_PATH_EXTERNAL_HOST_BINS CMake variable instead of environment; in sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake.d/OEQt5Toolchain.cmake this cmake variable is set to $ENV{OE_QMAKE_PATH_HOST_BINS}, there is no similar file for Aarch64 sysroot and there is no way to guess it's location in the build system without hardcoding. Anyway it won't help, because subject variable isn't set. -- Regards, Konstantin From samuli.piippo at qt.io Tue Jan 9 15:32:10 2018 From: samuli.piippo at qt.io (Samuli Piippo) Date: Tue, 9 Jan 2018 16:32:10 +0200 Subject: [Development] Coin, Boot2Qt, and OE_QMAKE_PATH_HOST_BINS variable In-Reply-To: <1674861515493630@web5g.yandex.ru> References: <1674861515493630@web5g.yandex.ru> Message-ID: On 09.01.2018 12:27, Konstantin Tokarev wrote: > Hello, > > I've tried to enable cross-compilation in Coin for QtWebKit 5.212 to improve > platform coverage in each build, however I've faced following problem. > > Our Linux cross-compilation platform is Boot2Qt which is based on meta-qt5 > Yocto layer. QtWebKit uses CMake internally, and Qt cmake config files on > this platform rely on environment variable OE_QMAKE_PATH_HOST_BINS > (see patch[1]). However, qmake-based builds seem to work fine without this > variable. > > I suppose that patch[1] is wrong. Can we revert it in Yocto images used in Coin? > > > [1] https://github.com/meta-qt5/meta-qt5/blob/268429962056a12e0e899612dafb433c257af5cf/recipes-qt/qt5/qtbase/0006-Pretend-Qt5-wasn-t-found-if-OE_QMAKE_PATH_EXTERNAL_H.patch > > You can see that this patch avtually checks OE_QMAKE_PATH_EXTERNAL_HOST_BINS > CMake variable instead of environment; in > sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake.d/OEQt5Toolchain.cmake > this cmake variable is set to $ENV{OE_QMAKE_PATH_HOST_BINS}, there is no > similar file for Aarch64 sysroot and there is no way to guess it's location in the build > system without hardcoding. Anyway it won't help, because subject variable isn't set. > Qmake based projects work in Coin since they do not use any of the Qt files already present in the toolchain, but it seems cmake based projects now work a bit differently. Even if we revert that patch, cmake would still be using wrong files from the sysroot and not from the Qt it's testing against in /home/qt/work/install/lib/cmake From annulen at yandex.ru Tue Jan 9 15:56:58 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 09 Jan 2018 17:56:58 +0300 Subject: [Development] Coin, Boot2Qt, and OE_QMAKE_PATH_HOST_BINS variable In-Reply-To: References: <1674861515493630@web5g.yandex.ru> Message-ID: <162351515509818@web29o.yandex.ru> 09.01.2018, 17:32, "Samuli Piippo" : > On 09.01.2018 12:27, Konstantin Tokarev wrote: >>  Hello, >> >>  I've tried to enable cross-compilation in Coin for QtWebKit 5.212 to improve >>  platform coverage in each build, however I've faced following problem. >> >>  Our Linux cross-compilation platform is Boot2Qt which is based on meta-qt5 >>  Yocto layer. QtWebKit uses CMake internally, and Qt cmake config files on >>  this platform rely on environment variable OE_QMAKE_PATH_HOST_BINS >>  (see patch[1]). However, qmake-based builds seem to work fine without this >>  variable. >> >>  I suppose that patch[1] is wrong. Can we revert it in Yocto images used in Coin? >> >>  [1] https://github.com/meta-qt5/meta-qt5/blob/268429962056a12e0e899612dafb433c257af5cf/recipes-qt/qt5/qtbase/0006-Pretend-Qt5-wasn-t-found-if-OE_QMAKE_PATH_EXTERNAL_H.patch >> >>  You can see that this patch avtually checks OE_QMAKE_PATH_EXTERNAL_HOST_BINS >>  CMake variable instead of environment; in >>  sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake.d/OEQt5Toolchain.cmake >>  this cmake variable is set to $ENV{OE_QMAKE_PATH_HOST_BINS}, there is no >>  similar file for Aarch64 sysroot and there is no way to guess it's location in the build >>  system without hardcoding. Anyway it won't help, because subject variable isn't set. > > Qmake based projects work in Coin since they do not use any of the Qt files > already present in the toolchain, but it seems cmake based projects now work > a bit differently. Even if we revert that patch, cmake would still be using > wrong files from the sysroot and not from the Qt it's testing against > in /home/qt/work/install/lib/cmake Thanks for your help, indeed my build is using wrong cmake config files Build log is at [1]. It runs cmake as /home/qt/work/qt/qtwebkit -DPORT=Qt -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=/home/qt/work/qt/qtwebkit/qmake_toolchain.cmake -DUSE_LIBHYPHEN=OFF -DCMAKE_PREFIX_PATH="/home/qt/work/install" Somehow config files from /home/qt/work/install are not picked. [1] https://testresults.qt.io/logs/qt/qtwebkit/400c59f8405a9cfb81d735cc40b0307f92b6aec3/LinuxUbuntu_16_04x86_64LinuxQEMUarmv7GCCqtci-linux-Ubuntu-16.04-x86_64-1-b46ac1Release/eec2223c1df502e6b17ef9acf06267b848088518/build_1515464652/log.txt.gz -- Regards, Konstantin From annulen at yandex.ru Tue Jan 9 15:56:58 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 09 Jan 2018 17:56:58 +0300 Subject: [Development] Coin, Boot2Qt, and OE_QMAKE_PATH_HOST_BINS variable In-Reply-To: References: <1674861515493630@web5g.yandex.ru> Message-ID: <162351515509818@web29o.yandex.ru> 09.01.2018, 17:32, "Samuli Piippo" : > On 09.01.2018 12:27, Konstantin Tokarev wrote: >>  Hello, >> >>  I've tried to enable cross-compilation in Coin for QtWebKit 5.212 to improve >>  platform coverage in each build, however I've faced following problem. >> >>  Our Linux cross-compilation platform is Boot2Qt which is based on meta-qt5 >>  Yocto layer. QtWebKit uses CMake internally, and Qt cmake config files on >>  this platform rely on environment variable OE_QMAKE_PATH_HOST_BINS >>  (see patch[1]). However, qmake-based builds seem to work fine without this >>  variable. >> >>  I suppose that patch[1] is wrong. Can we revert it in Yocto images used in Coin? >> >>  [1] https://github.com/meta-qt5/meta-qt5/blob/268429962056a12e0e899612dafb433c257af5cf/recipes-qt/qt5/qtbase/0006-Pretend-Qt5-wasn-t-found-if-OE_QMAKE_PATH_EXTERNAL_H.patch >> >>  You can see that this patch avtually checks OE_QMAKE_PATH_EXTERNAL_HOST_BINS >>  CMake variable instead of environment; in >>  sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake.d/OEQt5Toolchain.cmake >>  this cmake variable is set to $ENV{OE_QMAKE_PATH_HOST_BINS}, there is no >>  similar file for Aarch64 sysroot and there is no way to guess it's location in the build >>  system without hardcoding. Anyway it won't help, because subject variable isn't set. > > Qmake based projects work in Coin since they do not use any of the Qt files > already present in the toolchain, but it seems cmake based projects now work > a bit differently. Even if we revert that patch, cmake would still be using > wrong files from the sysroot and not from the Qt it's testing against > in /home/qt/work/install/lib/cmake Thanks for your help, indeed my build is using wrong cmake config files Build log is at [1]. It runs cmake as /home/qt/work/qt/qtwebkit -DPORT=Qt -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=/home/qt/work/qt/qtwebkit/qmake_toolchain.cmake -DUSE_LIBHYPHEN=OFF -DCMAKE_PREFIX_PATH="/home/qt/work/install" Somehow config files from /home/qt/work/install are not picked. [1] https://testresults.qt.io/logs/qt/qtwebkit/400c59f8405a9cfb81d735cc40b0307f92b6aec3/LinuxUbuntu_16_04x86_64LinuxQEMUarmv7GCCqtci-linux-Ubuntu-16.04-x86_64-1-b46ac1Release/eec2223c1df502e6b17ef9acf06267b848088518/build_1515464652/log.txt.gz -- Regards, Konstantin From robert.loehning at qt.io Tue Jan 9 16:42:51 2018 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Tue, 9 Jan 2018 16:42:51 +0100 Subject: [Development] [FYI] the new way to retarget gerrit changes In-Reply-To: <20180108134015.GA23646@troll08> References: <20180108134015.GA23646@troll08> Message-ID: <7266f29b-5626-9f19-9e66-b17d28e3a910@qt.io> Am 08.01.2018 um 14:40 schrieb Oswald Buddenhagen: > On Mon, Sep 12, 2016 at 02:39:57PM +0300, Orgad Shaneh wrote: >> Either extend the sanity bot, or create a new bot, which listens on >> gerrit's event stream. >> If the change's owner (or an approver?) posts a comment reading "Please >> retarget ", run your script on the server side. You need some >> sanity test that ensures this branch exists etc... >> > ... which he implemented, and it's deployed now. > > for simplicity, only the change owner may issue the command. for other > cases, you still need to go through an admin. the same is advisable for > batch requests, but do as you wish. > > the regex is > > /^(?:gerrit-)?bot:\h*(?:please\h+)?move\h+(?:back\h+)?to\h+(?:branch\h+)?([\w.]*\w)\b/im > > which boils down to "bot: move to " at the start of any line of > a gerrit cover message. Hi, thank you for making this possible. Will changes keep their approvals or will those be lost so that approvers have to give them again on the new branch? Cheers, Robert From sergio.martins at kdab.com Tue Jan 9 18:10:29 2018 From: sergio.martins at kdab.com (Sergio Martins) Date: Tue, 09 Jan 2018 17:10:29 +0000 Subject: [Development] Time to switch to android-clang In-Reply-To: <2970546.jHGumfAVZe@tjmaciei-mobl1> References: <14d4cb98ca86e58afc68d6c8d3d8939b@kdab.com> <2970546.jHGumfAVZe@tjmaciei-mobl1> Message-ID: On 2017-12-19 16:18, Thiago Macieira wrote: > On terça-feira, 19 de dezembro de 2017 03:25:17 PST Sergio Martins > wrote: >> Furthermore, supporting both android and android-clang is a >> maintenance >> burden: the mkspecs are often broken, either because of a new Qt >> version >> or because of a new NDK version. Then you have to test not only gcc >> and >> clang, but also test builds with the older NDKs. >> So we should also bump the NDK. > > I'm not familiar with Android development and the difficulty in > maintaining > android-clang. But seeing as we're already doing that anyway, it should > be > less work to change to Clang. I'm all for upgraing compilers, so a +0.5 > for > me. > > However, please answer this: what kind of compatibility do we need and > for how > long do we need to provide it? That's a good question (maybe for TQC and Bogdan). Probably only source-compatibility. From what I've seen, people recompile their app and bundle Qt with it, there's no Binary Compat concern. Some people use a service called Ministro, which installs Qt on their phone system-wide. They can get updates for Qt patch releases without rebuilding their application. Regards, -- Sérgio Martins | sergio.martins at 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 From oswald.buddenhagen at qt.io Tue Jan 9 19:09:48 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 9 Jan 2018 19:09:48 +0100 Subject: [Development] [FYI] the new way to retarget gerrit changes In-Reply-To: <7266f29b-5626-9f19-9e66-b17d28e3a910@qt.io> References: <20180108134015.GA23646@troll08> <7266f29b-5626-9f19-9e66-b17d28e3a910@qt.io> Message-ID: <20180109180948.GA7363@troll08> On Tue, Jan 09, 2018 at 04:42:51PM +0100, Robert Löhning wrote: > Will changes keep their approvals or will those be lost so that > approvers have to give them again on the new branch? > this implementation calls the same underlying script as i do manually, so nothing changes. From annulen at yandex.ru Wed Jan 10 02:14:09 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 10 Jan 2018 04:14:09 +0300 Subject: [Development] Coin, Boot2Qt, and OE_QMAKE_PATH_HOST_BINS variable In-Reply-To: References: <1674861515493630@web5g.yandex.ru> Message-ID: <2383151515546849@web37g.yandex.ru> 09.01.2018, 17:32, "Samuli Piippo" : > On 09.01.2018 12:27, Konstantin Tokarev wrote: >>  Hello, >> >>  I've tried to enable cross-compilation in Coin for QtWebKit 5.212 to improve >>  platform coverage in each build, however I've faced following problem. >> >>  Our Linux cross-compilation platform is Boot2Qt which is based on meta-qt5 >>  Yocto layer. QtWebKit uses CMake internally, and Qt cmake config files on >>  this platform rely on environment variable OE_QMAKE_PATH_HOST_BINS >>  (see patch[1]). However, qmake-based builds seem to work fine without this >>  variable. >> >>  I suppose that patch[1] is wrong. Can we revert it in Yocto images used in Coin? >> >>  [1] https://github.com/meta-qt5/meta-qt5/blob/268429962056a12e0e899612dafb433c257af5cf/recipes-qt/qt5/qtbase/0006-Pretend-Qt5-wasn-t-found-if-OE_QMAKE_PATH_EXTERNAL_H.patch >> >>  You can see that this patch avtually checks OE_QMAKE_PATH_EXTERNAL_HOST_BINS >>  CMake variable instead of environment; in >>  sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake.d/OEQt5Toolchain.cmake >>  this cmake variable is set to $ENV{OE_QMAKE_PATH_HOST_BINS}, there is no >>  similar file for Aarch64 sysroot and there is no way to guess it's location in the build >>  system without hardcoding. Anyway it won't help, because subject variable isn't set. > > Qmake based projects work in Coin since they do not use any of the Qt files > already present in the toolchain, but it seems cmake based projects now work > a bit differently. Even if we revert that patch, cmake would still be using > wrong files from the sysroot and not from the Qt it's testing against > in /home/qt/work/install/lib/cmake I've fixed this issue - now correct Qt cmake config files are used, and they don't require any additional environment. However, I've faced another problem: ${Qt5Gui_OPENGL_LIBRARIES} and ${Qt5Gui_EGL_LIBRARIES} are empty. Unfortunately, I cannot see how used Qt5GuiConfigExtras.cmake looks like. https://testresults.qt.io/logs/qt/qtwebkit/76870b3d1c00663adc95680ad9f81cb8e548de74/LinuxUbuntu_16_04x86_64LinuxQEMUarmv7GCCqtci-linux-Ubuntu-16.04-x86_64-1-b46ac1Release/eec2223c1df502e6b17ef9acf06267b848088518/build_1515544911/log.txt.gz -- Regards, Konstantin From b.terrier at gmail.com Wed Jan 10 10:37:25 2018 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Wed, 10 Jan 2018 10:37:25 +0100 Subject: [Development] [FYI] the new way to retarget gerrit changes In-Reply-To: <20180109180948.GA7363@troll08> References: <20180108134015.GA23646@troll08> <7266f29b-5626-9f19-9e66-b17d28e3a910@qt.io> <20180109180948.GA7363@troll08> Message-ID: 2018-01-09 19:09 GMT+01:00 Oswald Buddenhagen : > On Tue, Jan 09, 2018 at 04:42:51PM +0100, Robert Löhning wrote: > > Will changes keep their approvals or will those be lost so that > > approvers have to give them again on the new branch? > > > this implementation calls the same underlying script as i do manually, > so nothing changes. Hi, What happens if the change already exists in the target branch? As a real example I have https://codereview.qt-project.org/#/c/197888/ that should be retargeted to the dev branch. However, as I am quite new to gerrit I have made the mistake to push to dev thinking it would retarget, but effectively creating a new change: https://codereview.qt-project.org/#/c/214657/ Regards, Benjamin -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Wed Jan 10 11:06:20 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 10 Jan 2018 10:06:20 +0000 Subject: [Development] [FYI] the new way to retarget gerrit changes In-Reply-To: References: <20180108134015.GA23646@troll08> <7266f29b-5626-9f19-9e66-b17d28e3a910@qt.io> <20180109180948.GA7363@troll08>, Message-ID: Benjamin TERRIER (10 January 2018 10:37) > What happens if the change already exists in the target branch? > > As a real example I have https://codereview.qt-project.org/#/c/197888/ > that should be retargeted to the dev branch. However, as I am quite > new to gerrit I have made the mistake to push to dev thinking it would > retarget, but effectively creating a new change: > https://codereview.qt-project.org/#/c/214657/ Then you can just abandon the one on the old branch - this is the blunt way to retarget a change, that we've already had, at the cost of losing connection with the earlier patch sets and comments from reviewers on the review for the old branch. (It thus irritates reivewers.) If you ever find yourself needing to change branch *back* to the original, after such a change, you'll need to do it be reviving the abandoned change and abandoning the first-moved one. I suspect there's also a way for a gerrit admin to nuke the misguided review, if you ask nicely, but I'll let Ossi tell you about that, if it exists, Eddy. From oswald.buddenhagen at qt.io Wed Jan 10 11:23:35 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 10 Jan 2018 11:23:35 +0100 Subject: [Development] [FYI] the new way to retarget gerrit changes In-Reply-To: References: <20180108134015.GA23646@troll08> <7266f29b-5626-9f19-9e66-b17d28e3a910@qt.io> <20180109180948.GA7363@troll08> Message-ID: <20180110102335.GB8441@troll08> On Wed, Jan 10, 2018 at 10:37:25AM +0100, Benjamin TERRIER wrote: > What happens if the change already exists in the target branch? > the system would tell you to contact an admin if you tried nonetheless. > [3]https://codereview.qt-project.org/#/c/214657/ > it's gone. From b.terrier at gmail.com Wed Jan 10 11:29:13 2018 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Wed, 10 Jan 2018 11:29:13 +0100 Subject: [Development] [FYI] the new way to retarget gerrit changes In-Reply-To: <20180110102335.GB8441@troll08> References: <20180108134015.GA23646@troll08> <7266f29b-5626-9f19-9e66-b17d28e3a910@qt.io> <20180109180948.GA7363@troll08> <20180110102335.GB8441@troll08> Message-ID: 2018-01-10 11:23 GMT+01:00 Oswald Buddenhagen : > On Wed, Jan 10, 2018 at 10:37:25AM +0100, Benjamin TERRIER wrote: > > What happens if the change already exists in the target branch? > > > the system would tell you to contact an admin if you tried nonetheless. > > > [3]https://codereview.qt-project.org/#/c/214657/ > > > it's gone. Thanks! I tried the bot command, it worked like a charm. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederik.gladhorn at qt.io Wed Jan 10 15:25:03 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 10 Jan 2018 15:25:03 +0100 Subject: [Development] QML and Qt Quick versioning of our modules In-Reply-To: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> References: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> Message-ID: <1695160.h8kdQ1ft31@frederik-thinkcentre-m93p> Hi, I'll start turning this thread into a QUIP here (currently empty placeholder commit): https://codereview.qt-project.org/#/c/215625/ I'll update the list when I have written something. In the mean time I'd like to ask for this to become QUIP #99 and hereby reserve the number. Cheers, Frederik On torsdag 7. desember 2017 14.53.06 CET Frederik Gladhorn wrote: > Hi all, > > I've lately been discussing with a few people in The Qt Company about our > versioning. > Historically it was a good idea to not couple Qt Quick too tightly to > general Qt releases. There were quite some constraints and added > flexibility was nice. Qt Quick has matured a lot though, so I think it's > time to consider making everyone's lives easier by cleaning up our version > chaos. > See also J-P's previous mail here: http://lists.qt-project.org/pipermail/ > development/2015-September/023200.html > > Examples are the version section in here: > https://doc.qt.io/qt-5/qtquickcontrols2-index.html > And a general confusion around which version does what. > Since we so far don't keep copies of old functions around (as far as I'm > aware at least), I don't think there's a huge value in the versioning > system in the first place. > It only gives one important guarantee: if you added a property/type/name and > import a defined version, you don't suddenly get conflicts because we > introduced the same name. > > Some modules started to copy the Qt version, e.g. Multimedia, that's pretty > easy to remember and a good start in my opinion. > > I have several ideas and I'm unsure how hard they would be to implement, so > I'll list things from easy to hard. > > 1) sync minor versions to Qt release version: > For Qt 5.11, we would provide QtQuick.Controls 2.11 > This way, the challenge for the user is only to find out if it's version 1, > 2 or 5. > > 2) Make the minor version import optional and we pick the lastest. This > should be optional to prevent the name clashes described above and shifts > the risk to the user. > In practice I'd expect this to be pretty safe. > import QtQuick.Controls 2 would then give the latest version available. > > 3) Make even the major version optional and we'd pick up the latest version. > import QtQuick.Controls would give version 2.11 with Qt 5.11. > > I don't see us releasing most of the QML/Qt Quick modules independent of the > rest of Qt any time soon, so I hope this will make things easier for > everyone. I'm sure there are even better ideas out there, this is just my > version and current thinking, I hope for constructive suggestions :) > > In the end I want this to be easier for Qt users and also to lessen our > maintenance burden and the need to look up versions, explain the scheme and > reduce the confusion. > > Luckily we now have qmlRegisterModule(QT_VERSION_MAJOR, QT_VERSION_MINOR) to > help registering the current versions already. > > Cheers, > Frederik > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tpham3783 at gmail.com Thu Jan 11 18:49:31 2018 From: tpham3783 at gmail.com (Toan Pham) Date: Thu, 11 Jan 2018 12:49:31 -0500 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: <541394F3-306E-4B79-85F1-6C83A966C53B@qt.io> References: <5120988.Mb6HJglHXC@tjmaciei-mobl1> <5244576.1dG1z4Tzuh@tjmaciei-mobl1> <541394F3-306E-4B79-85F1-6C83A966C53B@qt.io> Message-ID: Thiago, I managed to get the build completed by performing these steps: 1. Followed your advise on enabling sse2 because it is a hard-requirement. 2. Patched libvpx heavily to disable avx+avx2/sse3+ (see attached patch) 3. Patched libyuv (see attached patch) 4. Patched qwebengine/src/core/Makefile.gn_run to launch ninja in single thread - otherwise build w/ terminate by Out-Of-Memory manager. 5. Used 32bit native linker even though you recommended a 64bit linker. Step# 2 and 3 were needed because the compiler I was using was optimized for pentium4, it wouldn't be able to compile/link-in SIMD instructions beyond SSE2. After all that hard work, minimal webengine browser (located at qtwebengine/examples/webengine/minimal) did not show anything when I launched it (see attached screenshot). I also launched the same browser which worked fine under lxc-ubuntu16.04-32bit; but did not show anything within the chroot environment of the pentium4 build. OnPageLoad event of qtwebengine showed that webpage loaded successfully; so it made me to believe that this is an issue with qwebenginewidget. FYI, within the same build environment, I was able to run QtWebKit from Qt-5.x a few months back. Please help if you know what possibly happened to qwebengineview not rendering anything on the view. Thank you, TP On Mon, Jan 8, 2018 at 3:21 AM, Lars Knoll wrote: > > > >> For me, it's quite simple: > >> No (opensource/commercial) Qt CI = No (opensource/commercial) Qt > >> binaries = No (opensource/commercial) support. > > > > No CI, see above. > > No binaries, build from sources. > > No support, sorry, I can't comment. > > Just a quick comment from TQtC’s perspective on this: We do commercially > support more platforms than we create binaries for. Linux/32bit is > certainly one of those. > > But as Thiago pointed out, those platforms are not always tested quite as > well (unfortunately we can’t possibly test all combinations of OS/CPU > architecture/distribution in our CI). > > Cheers, > Lars > > > > >> If you don't build and test on a regular basis, it can break at any > >> moment without anyone noticing (and it did happened at least once) > > > > You're right, but given all the other permutations, we're very likely > covered > > at a good 99% certainty. > > > >> PS: In case you think I'm ranting for free here, i would like to say > >> (again) that I think Qt is a great piece of (opensource/commercial) > >> SW, and big thumb up to anyone behind this, The Qt Project, The Qt > >> Company, Intel, ICS, KDAB, KDE, ... and everyone else, individual or > >> corporate. > > > > We're having a constructive conversation, don't worry. > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qwebengine.pentium4-5.10.0.patch Type: text/x-patch Size: 39980 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: desk0.png Type: image/png Size: 238481 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: desk1.png Type: image/png Size: 211171 bytes Desc: not available URL: From tony.sarajarvi at qt.io Fri Jan 12 07:25:59 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Fri, 12 Jan 2018 06:25:59 +0000 Subject: [Development] CI down. OpenNebula VM has crashed. Message-ID: Hi We've had a breakdown of the hypervisor we are using in the CI. We began investigations. Regards, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Fri Jan 12 08:16:01 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Fri, 12 Jan 2018 07:16:01 +0000 Subject: [Development] CI down. OpenNebula VM has crashed. In-Reply-To: References: Message-ID: We're back online, but don't know the reason for the crash yet. We'll monitor. -T From: Tony Sarajärvi Sent: perjantai 12. tammikuuta 2018 8.26 To: development at qt-project.org Subject: CI down. OpenNebula VM has crashed. Hi We've had a breakdown of the hypervisor we are using in the CI. We began investigations. Regards, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From paolo.angelelli at qt.io Fri Jan 12 12:49:32 2018 From: paolo.angelelli at qt.io (Paolo Angelelli) Date: Fri, 12 Jan 2018 12:49:32 +0100 Subject: [Development] [FYI] the new way to retarget gerrit changes In-Reply-To: <20180108134015.GA23646@troll08> References: <20180108134015.GA23646@troll08> Message-ID: <20180112124932.1ad93281@qdesktop> On Mon, 8 Jan 2018 14:40:15 +0100 Oswald Buddenhagen wrote: > On Mon, Sep 12, 2016 at 02:39:57PM +0300, Orgad Shaneh wrote: > > Either extend the sanity bot, or create a new bot, which listens on > > gerrit's event stream. > > If the change's owner (or an approver?) posts a comment reading "Please > > retarget ", run your script on the server side. You need some > > sanity test that ensures this branch exists etc... > > > ... which he implemented, and it's deployed now. > > for simplicity, only the change owner may issue the command. for other > cases, you still need to go through an admin. the same is advisable for > batch requests, but do as you wish. > > the regex is > > /^(?:gerrit-)?bot:\h*(?:please\h+)?move\h+(?:back\h+)?to\h+(?:branch\h+)?([\w.]*\w)\b/im > > which boils down to "bot: move to " at the start of any line of > a gerrit cover message. Tried: bot: move to wip/navigation got the change moved to branch "wip" Bug or my mistake? From oswald.buddenhagen at qt.io Fri Jan 12 13:03:52 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 12 Jan 2018 13:03:52 +0100 Subject: [Development] [FYI] the new way to retarget gerrit changes In-Reply-To: <20180112124932.1ad93281@qdesktop> References: <20180108134015.GA23646@troll08> <20180112124932.1ad93281@qdesktop> Message-ID: <20180112120352.GA25451@troll08> On Fri, Jan 12, 2018 at 12:49:32PM +0100, Paolo Angelelli wrote: > On Mon, 8 Jan 2018 14:40:15 +0100 Oswald Buddenhagen wrote: > > the regex is > > > > /^(?:gerrit-)?bot:\h*(?:please\h+)?move\h+(?:back\h+)?to\h+(?:branch\h+)?([\w.]*\w)\b/im > > > > which boils down to "bot: move to " at the start of any line of > > a gerrit cover message. > > > Tried: > bot: move to wip/navigation > > got the change moved to branch "wip" > Bug or my mistake? > bug, pretty obvious from the quoted regex. https://codereview.qt-project.org/216558 From jani.heikkinen at qt.io Fri Jan 12 14:27:15 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 12 Jan 2018 13:27:15 +0000 Subject: [Development] Qt 5.9.4 snapshot available In-Reply-To: References: Message-ID: Hi! We have finally Qt 5.9.4 snapshot available in online repositories. You can add/update it via online installer like earlier. Please test the snapshot now & report all findings in Jira. And please inform me immediately if you find something which must block the Qt 5.9.4 release. But remember: We won't block release quite easily: If issue has been in Qt 5.9.3 or earlier then by default it won't block Qt 5.9.4. Snapshot isn't yet final Qt 5.9.4 release but should be close: Blocker list is almost empty and only few already integrated changes are missing from snapshot. We will release Qt 5.9.4 during next week if nothing really serious reported from this snapshot br, Jani From tpham3783 at gmail.com Fri Jan 12 15:54:53 2018 From: tpham3783 at gmail.com (Toan Pham) Date: Fri, 12 Jan 2018 09:54:53 -0500 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <5120988.Mb6HJglHXC@tjmaciei-mobl1> <5244576.1dG1z4Tzuh@tjmaciei-mobl1> <541394F3-306E-4B79-85F1-6C83A966C53B@qt.io> Message-ID: I am suspecting that the reason why qtwebengineview did not render because it could not establish IPC connection to qtwebengineprocess. As seen in the error below, qtwebengineview aborted when it received unexpected number of bytes from the IPC initialization call (recvmsg): "unexpected number of handles". The second error is related to QT not able to allocate more memory: "FATAL:memory.cc(22)] Out of memory. size=262144". The system had more than 1.8G of RAM, so I do not see how it is possible. Reference: Error and stack trace of application: >> [13118:13122:0112/095238.425618:ERROR:broker_posix.cc(46)] Received unexpected number of handles My assumption here is that qt could not establish IPC connection with webengineprocess! >> [13118:13122:0112/095238.425832:WARNING:client_shared_bitmap_manager.cc(98)] Browser failed to allocate shared memory >> [13118:13122:0112/095238.425986:FATAL:memory.cc(22)] Out of memory. size=262144 >> #0 0x0000412c4f36 >> #1 0x0000412c4c5d >> #2 0x0000412d6c4d Obviously, bitmap manager could not allocate memory. The question is why? system had pretty of RAM. On Thu, Jan 11, 2018 at 12:49 PM, Toan Pham wrote: > > Thiago, > > I managed to get the build completed by performing these steps: > > 1. Followed your advise on enabling sse2 because it is a > hard-requirement. > 2. Patched libvpx heavily to disable avx+avx2/sse3+ (see attached patch) > 3. Patched libyuv (see attached patch) > 4. Patched qwebengine/src/core/Makefile.gn_run to launch ninja in > single thread - otherwise build w/ terminate by Out-Of-Memory manager. > 5. Used 32bit native linker even though you recommended a 64bit linker. > > Step# 2 and 3 were needed because the compiler I was using was optimized > for pentium4, it wouldn't be able to compile/link-in SIMD instructions > beyond SSE2. > > > After all that hard work, minimal webengine browser (located at > qtwebengine/examples/webengine/minimal) did not show anything when I > launched it (see attached screenshot). I also launched the same browser > which worked fine under lxc-ubuntu16.04-32bit; but did not show anything > within the chroot environment of the pentium4 build. OnPageLoad event of > qtwebengine showed that webpage loaded successfully; so it made me to > believe that this is an issue with qwebenginewidget. FYI, within the same > build environment, I was able to run QtWebKit from Qt-5.x a few months > back. Please help if you know what possibly happened to qwebengineview not > rendering anything on the view. > > > Thank you, > > TP > > > > > On Mon, Jan 8, 2018 at 3:21 AM, Lars Knoll wrote: > >> > >> >> For me, it's quite simple: >> >> No (opensource/commercial) Qt CI = No (opensource/commercial) Qt >> >> binaries = No (opensource/commercial) support. >> > >> > No CI, see above. >> > No binaries, build from sources. >> > No support, sorry, I can't comment. >> >> Just a quick comment from TQtC’s perspective on this: We do commercially >> support more platforms than we create binaries for. Linux/32bit is >> certainly one of those. >> >> But as Thiago pointed out, those platforms are not always tested quite as >> well (unfortunately we can’t possibly test all combinations of OS/CPU >> architecture/distribution in our CI). >> >> Cheers, >> Lars >> >> > >> >> If you don't build and test on a regular basis, it can break at any >> >> moment without anyone noticing (and it did happened at least once) >> > >> > You're right, but given all the other permutations, we're very likely >> covered >> > at a good 99% certainty. >> > >> >> PS: In case you think I'm ranting for free here, i would like to say >> >> (again) that I think Qt is a great piece of (opensource/commercial) >> >> SW, and big thumb up to anyone behind this, The Qt Project, The Qt >> >> Company, Intel, ICS, KDAB, KDE, ... and everyone else, individual or >> >> corporate. >> > >> > We're having a constructive conversation, don't worry. >> > >> > -- >> > Thiago Macieira - thiago.macieira (AT) intel.com >> > Software Architect - Intel Open Source Technology Center >> > >> > _______________________________________________ >> > Development mailing list >> > Development at qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/development >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Fri Jan 12 16:22:56 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 12 Jan 2018 18:22:56 +0300 Subject: [Development] QMAKE_EXTRA_COMPILERS does not work on Android in case the ANDROID_PACKAGE_SOURCE_DIR is empty Message-ID: Hi all. I need to use a custom target to build of external shared library *.so, with a custom build system (e.g. using the NDK directly) and to link with. I faced with a strange behavior of QMAKE_EXTRA_COMPILERS on Android, which is that the qmake does not creates a "compiler_foo_" target in the output Makefile for my target if the ANDROID_PACKAGE_SOURCE_DIR is not set. So, the desired build step does not called at all. O_O E.g. I have following rules in the *.pro file:  ...  android {      foo.name = Foo compiler      foo.input = FOO      foo.output = FOO_PATH      # Build command.      foo.commands = (custom build command)      # Custom additional cleanup targets.      foo.clean += (custom cleanup command)      foo.CONFIG += target_predeps      QMAKE_EXTRA_COMPILERS += foo      # Add the generated library into the resulting apk.      ANDROID_EXTRA_LIBS = $$GST_MODULE_PATH  }  ... In this case I see in Makefile following:  ...  compiler_foo_make_all:  compiler_foo_clean:     (set of custom cleanup commands)  ... But, if I try to add any not empty ANDROID_PACKAGE_SOURCE_DIR to the *.pro file:  ...  android {      ANDROID_PACKAGE_SOURCE_DIR =      ....      ....  }  ... then the resulting Makefile contains all what need:  ...  OBJECTS       = ...  ...  compiler_gst_make_all:  compiler_gst_clean:      (set of custom cleanup commands)  ...  : foo      (set of custom build commands)  ... How can I fix it? Because in a real project I will to use the QMAKE_EXTRA_COMPILERS in a 'static library' template project, which does not contains any Android's java sources and so on. BR, Denis From denis.shienkov at gmail.com Fri Jan 12 16:53:10 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 12 Jan 2018 18:53:10 +0300 Subject: [Development] QMAKE_EXTRA_COMPILERS does not work on Android in case the ANDROID_PACKAGE_SOURCE_DIR is empty In-Reply-To: References: Message-ID: I'm very sorry, it is my fail. :(( 12.01.2018 18:22, Denis Shienkov пишет: > Hi all. > > I need to use a custom target to build of external shared library *.so, > with a custom build system (e.g. using the NDK directly) and to link > with. > > I faced with a strange behavior of QMAKE_EXTRA_COMPILERS on Android, > which is that the qmake does not creates a "compiler_foo_" target in > the output Makefile for my target if the ANDROID_PACKAGE_SOURCE_DIR is > not set. So, the desired build step does not called at all. O_O > > E.g. I have following rules in the *.pro file: > >  ... >  android { > >      foo.name = Foo compiler >      foo.input = FOO >      foo.output = FOO_PATH > >      # Build command. >      foo.commands = (custom build command) > >      # Custom additional cleanup targets. >      foo.clean += (custom cleanup command) > >      foo.CONFIG += target_predeps > >      QMAKE_EXTRA_COMPILERS += foo > >      # Add the generated library into the resulting apk. >      ANDROID_EXTRA_LIBS = $$GST_MODULE_PATH > >  } >  ... > > In this case I see in Makefile following: > >  ... >  compiler_foo_make_all: >  compiler_foo_clean: >     (set of custom cleanup commands) >  ... > > But, if I try to add any not empty ANDROID_PACKAGE_SOURCE_DIR > to the *.pro file: > >  ... >  android { >      ANDROID_PACKAGE_SOURCE_DIR = > >      .... >      .... >  } >  ... > > then the resulting Makefile contains all what need: > >  ... >  OBJECTS       = ... >  ... >  compiler_gst_make_all: >  compiler_gst_clean: >      (set of custom cleanup commands) >  ... >  : foo >      (set of custom build commands) >  ... > > How can I fix it? Because in a real project I will to use > the QMAKE_EXTRA_COMPILERS in a 'static library' template project, > which does not contains any Android's java sources and so on. > > BR, > Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From wim.delvaux at adaptiveplanet.com Fri Jan 12 18:39:17 2018 From: wim.delvaux at adaptiveplanet.com (wim delvaux) Date: Fri, 12 Jan 2018 18:39:17 +0100 Subject: [Development] Issue using QGraphicsProxyWidget and a QListWidget's scrollbars Message-ID: These are the settings with which I initialize my QGraphicsView setCacheMode(CacheBackground); setViewportUpdateMode(BoundingRectViewportUpdate); setRenderHint(QPainter::Antialiasing); setTransformationAnchor(AnchorUnderMouse); setInteractive( true ); setDragMode( QGraphicsView::ScrollHandDrag ); when I add a QListWidget it appears normally. However interacting with the widget is weird. 1. It seems i need to double click or something for it to focus. A Single click on the content of the listwidget never selects the item 2. scrollbar manipulation is even more tricky. First the Icon is the 'hand' icon using for panning the view. Most of the time with the cursor on the scrollbar, panning happens. Sometimes, after a few (double) clicks, the scrollbar finally decides to move but still with the 'hand' cursor. I also added a QLineEdit and that shows similar issues. Here getting focus to the field requires double click and the I-beam never appears What could be wrong ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Fri Jan 12 18:58:16 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 12 Jan 2018 20:58:16 +0300 Subject: [Development] qmake's custom install failed on Android Message-ID: Hi all, I need to use the INSTALLS feature on Android project to copy of some files to the desired location. For, example, this simple example fails at building for the install target: QT += quick CONFIG += c++11 SOURCES += main.cpp RESOURCES += qml.qrc foo_bar.files += $$PWD/main.cpp foo_bar.path = $$OUT_PWD/foobar INSTALLS += foo_bar ... with an error, like: "Unable to create a file or directory". If I try to change the Android's kit to e.g. Windows's kit, then my 'main.cpp' file copies fine. Is it a bug? Or I do something wrong? PS: I use Windows 10 host && Qt 5.9.3 for Android ARMv7 Kit. BR, Denis From oswald.buddenhagen at qt.io Fri Jan 12 19:49:22 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 12 Jan 2018 19:49:22 +0100 Subject: [Development] qmake's custom install failed on Android In-Reply-To: References: Message-ID: <20180112184922.GA16641@troll08> On Fri, Jan 12, 2018 at 08:58:16PM +0300, Denis Shienkov wrote: > I need to use the INSTALLS feature on Android project > to copy of some files to the desired location. > > foo_bar.path = $$OUT_PWD/foobar > INSTALLS += foo_bar > that's positively wrong. for a non-install shadow build, you can use COPIES (if you do that outside qt, you're doing it at your own risk; it doesn't work with the IDE generators). an actual INSTALLS would never point into OUT_PWD, i.e., the build dir. From denis.shienkov at gmail.com Fri Jan 12 20:31:14 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 12 Jan 2018 22:31:14 +0300 Subject: [Development] qmake's custom install failed on Android In-Reply-To: <20180112184922.GA16641@troll08> References: <20180112184922.GA16641@troll08> Message-ID: In a real project I need to copy an external *.java files to the android-build/src/org directory. Now, if I use the INSTALLS as following:     gst_java.files = $$libs_sourcedir/$$GST_SUPPORT_TARGET/android-sources/src/org/freedesktop/$$GST_MODULE_NAME/GStreamer.java     gst_java.path = /src/org/freedesktop/$$GST_MODULE_NAME     INSTALLS += gst_java then the resulting files are not copied to the android-build/src/org/freedesktop/ if the ANDROID_PACKAGE_SOURCE_DIR variable is defined. I doo not know how to use and ANDROID_PACKAGE_SOURCE_DIR and INSTALLS together... 12.01.2018 21:49, Oswald Buddenhagen пишет: > On Fri, Jan 12, 2018 at 08:58:16PM +0300, Denis Shienkov wrote: >> I need to use the INSTALLS feature on Android project >> to copy of some files to the desired location. >> >> foo_bar.path = $$OUT_PWD/foobar >> INSTALLS += foo_bar >> > that's positively wrong. > for a non-install shadow build, you can use COPIES (if you do that > outside qt, you're doing it at your own risk; it doesn't work with the > IDE generators). > an actual INSTALLS would never point into OUT_PWD, i.e., the build dir. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Fri Jan 12 21:00:45 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 12 Jan 2018 23:00:45 +0300 Subject: [Development] qmake's custom install failed on Android In-Reply-To: References: <20180112184922.GA16641@troll08> Message-ID: <11f0c89b-b682-2cf8-7b73-c1e80065dd35@gmail.com> > you can use COPIES It does not work as well if the ANDROID_PACKAGE_SOURCE_DIR is defined. 12.01.2018 22:31, Denis Shienkov пишет: > > In a real project I need to copy an external *.java > files to the android-build/src/org directory. > > Now, if I use the INSTALLS as following: > >     gst_java.files = > $$libs_sourcedir/$$GST_SUPPORT_TARGET/android-sources/src/org/freedesktop/$$GST_MODULE_NAME/GStreamer.java >     gst_java.path = /src/org/freedesktop/$$GST_MODULE_NAME >     INSTALLS += gst_java > > then the resulting files are not copied to the > android-build/src/org/freedesktop/ if the > ANDROID_PACKAGE_SOURCE_DIR variable is defined. > > I doo not know how to use and ANDROID_PACKAGE_SOURCE_DIR > and INSTALLS together... > > > 12.01.2018 21:49, Oswald Buddenhagen пишет: >> On Fri, Jan 12, 2018 at 08:58:16PM +0300, Denis Shienkov wrote: >>> I need to use the INSTALLS feature on Android project >>> to copy of some files to the desired location. >>> >>> foo_bar.path = $$OUT_PWD/foobar >>> INSTALLS += foo_bar >>> >> that's positively wrong. >> for a non-install shadow build, you can use COPIES (if you do that >> outside qt, you're doing it at your own risk; it doesn't work with the >> IDE generators). >> an actual INSTALLS would never point into OUT_PWD, i.e., the build dir. >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Fri Jan 12 21:24:59 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 12 Jan 2018 23:24:59 +0300 Subject: [Development] qmake's custom install failed on Android In-Reply-To: <11f0c89b-b682-2cf8-7b73-c1e80065dd35@gmail.com> References: <20180112184922.GA16641@troll08> <11f0c89b-b682-2cf8-7b73-c1e80065dd35@gmail.com> Message-ID: <3c112e66-378c-493e-017a-faf89f6aeffc@gmail.com> This solution: https://stackoverflow.com/questions/25929467/qt-android-location-of-java-files-common-to-different-projects does not work as well. 12.01.2018 23:00, Denis Shienkov пишет: > > > you can use COPIES > > It does not work as well if the ANDROID_PACKAGE_SOURCE_DIR is defined. > > > 12.01.2018 22:31, Denis Shienkov пишет: >> >> In a real project I need to copy an external *.java >> files to the android-build/src/org directory. >> >> Now, if I use the INSTALLS as following: >> >>     gst_java.files = >> $$libs_sourcedir/$$GST_SUPPORT_TARGET/android-sources/src/org/freedesktop/$$GST_MODULE_NAME/GStreamer.java >>     gst_java.path = /src/org/freedesktop/$$GST_MODULE_NAME >>     INSTALLS += gst_java >> >> then the resulting files are not copied to the >> android-build/src/org/freedesktop/ if the >> ANDROID_PACKAGE_SOURCE_DIR variable is defined. >> >> I doo not know how to use and ANDROID_PACKAGE_SOURCE_DIR >> and INSTALLS together... >> >> >> 12.01.2018 21:49, Oswald Buddenhagen пишет: >>> On Fri, Jan 12, 2018 at 08:58:16PM +0300, Denis Shienkov wrote: >>>> I need to use the INSTALLS feature on Android project >>>> to copy of some files to the desired location. >>>> >>>> foo_bar.path = $$OUT_PWD/foobar >>>> INSTALLS += foo_bar >>>> >>> that's positively wrong. >>> for a non-install shadow build, you can use COPIES (if you do that >>> outside qt, you're doing it at your own risk; it doesn't work with the >>> IDE generators). >>> an actual INSTALLS would never point into OUT_PWD, i.e., the build dir. >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Sat Jan 13 17:34:53 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Sat, 13 Jan 2018 19:34:53 +0300 Subject: [Development] Mismatch of display resolutions and window sizes in Android applications Message-ID: Hi all. Rigth now I faced with the strange issue is that the QML window size (screen) does not correspond to the display resolution. For example, I have the "ASUS ZenFone 4 Max ZC554KL" smartphone which has display resolution as 1280x720 pixels. But if I run there the QML application and try to print out the ApplicationWindow size, then it is 360x568 or 640x288 pixels, depends on orientation. O_o I have checked the same and on other smartphones, and see that there the situation is similar. E.g. for the "Samsung Galaxy Ace 3 GT-S7270" with 800x480 display I got 320x460 or 533x247 pixels of my ApplicationWindow. For example if try to use the QtLocation module, then any maps looks ugly. It is very bad surprise for me... Because, seems, now I can not write any applications with high resolusion (or, at least to operate with a real resolutions from my QML code). Is there are any tricks to fix it? PS: Some Android's firmwares (e.g. Cyanogen)  allows to change the DPI, and with the minimum DPI the ApplicationWindow size increases a bit.. But it is not an option anyway. BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Sat Jan 13 19:27:03 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Sat, 13 Jan 2018 21:27:03 +0300 Subject: [Development] Mismatch of display resolutions and window sizes in Android applications In-Reply-To: References: Message-ID: The problem was in Qt::AA_EnableHighDpiScaling option. 13.01.2018 19:34, Denis Shienkov пишет: > > Hi all. > > Rigth now I faced with the strange issue is that the QML > window size (screen) does not correspond to the display > resolution. > > For example, I have the "ASUS ZenFone 4 Max ZC554KL" > smartphone which has display resolution as 1280x720 pixels. > > But if I run there the QML application and try to print out > the ApplicationWindow size, then it is 360x568 or 640x288 > pixels, depends on orientation. O_o > > I have checked the same and on other smartphones, and see > that there the situation is similar. E.g. for the > "Samsung Galaxy Ace 3 GT-S7270" with 800x480 display I got > 320x460 or 533x247 pixels of my ApplicationWindow. > > For example if try to use the QtLocation module, then any > maps looks ugly. > > It is very bad surprise for me... Because, seems, now I can > not write any applications with high resolusion (or, at least > to operate with a real resolutions from my QML code). > > Is there are any tricks to fix it? > > PS: Some Android's firmwares (e.g. Cyanogen)  allows to change > the DPI, and with the minimum DPI the ApplicationWindow size > increases a bit.. But it is not an option anyway. > > BR, > Denis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ritt.ks at gmail.com Sat Jan 13 20:57:00 2018 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Sat, 13 Jan 2018 23:57:00 +0400 Subject: [Development] Mismatch of display resolutions and window sizes in Android applications In-Reply-To: References: Message-ID: Plz use https://bugreports.qt.io/ for bug reports and feature requests. Qt Development ML is for discussions around Qt development, not even about development with Qt. Regards, Konstantin 2018-01-13 22:27 GMT+04:00 Denis Shienkov : > The problem was in Qt::AA_EnableHighDpiScaling option. > > 13.01.2018 19:34, Denis Shienkov пишет: > > Hi all. > > Rigth now I faced with the strange issue is that the QML > window size (screen) does not correspond to the display > resolution. > > For example, I have the "ASUS ZenFone 4 Max ZC554KL" > smartphone which has display resolution as 1280x720 pixels. > > But if I run there the QML application and try to print out > the ApplicationWindow size, then it is 360x568 or 640x288 > pixels, depends on orientation. O_o > > I have checked the same and on other smartphones, and see > that there the situation is similar. E.g. for the > "Samsung Galaxy Ace 3 GT-S7270" with 800x480 display I got > 320x460 or 533x247 pixels of my ApplicationWindow. > > For example if try to use the QtLocation module, then any > maps looks ugly. > > It is very bad surprise for me... Because, seems, now I can > not write any applications with high resolusion (or, at least > to operate with a real resolutions from my QML code). > > Is there are any tricks to fix it? > > PS: Some Android's firmwares (e.g. Cyanogen) allows to change > the DPI, and with the minimum DPI the ApplicationWindow size > increases a bit.. But it is not an option anyway. > > BR, > Denis > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleravat at witekio.com Sun Jan 14 18:49:48 2018 From: aleravat at witekio.com (Adrien LERAVAT) Date: Sun, 14 Jan 2018 17:49:48 +0000 Subject: [Development] QtCoap: QNAM-like API or not Message-ID: Hi all, Before feature freeze, we wanted to challenge the current API for the CoAP module. It is currently similar to QNAM APIs: \code QCoapClient client; QCoapReply *reply = client.get(QUrl("1.2.3.4:5683")); connect(reply, &QCoapReply::finished, this, &MyClass::onFinished); ... MyClass::onFinished(QCoapReply* reply) { qWarning() << reply->readAll(); reply->deleteLater(); } \endcode With the clear drawback of explicit memory management needed by users. We made some tests with a container/RAII object for the reply, and it seems fine, but before moving forward in this limited timeframe, we wanted to have your feedback. Sample below: \code QCoapClient client; QCoapRequest request = client.get(QUrl("1.2.3.4:5683")); connect(request.reply(), &QCoapReply::finished, this, &MyClass::onFinished); ... MyClass::onFinished(const QCoapRequest &request) { qWarning() << request.reply()->readAll(); } \endcode In that case, the QCoapReply life is managed with a QSharedPointer in the request. QCoapRequest does not inherit from QObject. Anyone sees a problem with this approach? As it wasn't merged to master yet, you can access the repo from its current submission: https://codereview.qt-project.org/#/c/201311/ Thanks, Adrien Leravat -------------- next part -------------- An HTML attachment was scrubbed... URL: From ville.voutilainen at gmail.com Sun Jan 14 20:51:41 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sun, 14 Jan 2018 21:51:41 +0200 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: References: Message-ID: On 14 January 2018 at 19:49, Adrien LERAVAT wrote: > With the clear drawback of explicit memory management needed by users. We > made > > some tests with a container/RAII object for the reply, and it seems fine, > but before > > moving forward in this limited timeframe, we wanted to have your feedback. > > Sample below: > > > \code > > QCoapClient client; > > QCoapRequest request = client.get(QUrl("1.2.3.4:5683")); > > connect(request.reply(), &QCoapReply::finished, this, &MyClass::onFinished); > > ... > > MyClass::onFinished(const QCoapRequest &request) > > { > > qWarning() << request.reply()->readAll(); > > } > > \endcode > > > In that case, the QCoapReply life is managed with a > QSharedPointer in the request. > > QCoapRequest does not inherit from QObject. Anyone sees a problem with this > approach? Doing automatic cleanup is certainly an improvement, but in addition to that, I think it's useful if the user can explicitly cleanup as well, as soon as she's done with the reply, without waiting for the lifetime of the request to end. From wim.delvaux at adaptiveplanet.com Mon Jan 15 02:14:56 2018 From: wim.delvaux at adaptiveplanet.com (wim delvaux) Date: Mon, 15 Jan 2018 02:14:56 +0100 Subject: [Development] Qt 5.10 : arrow keys not working in QGraphicsProxyWidget Message-ID: Hi all, To cut it short (too short ?) I have QLineEdit and QListWidget widgets embedded in a QGraphicsScene. Interacting works partially : Mouse clicking and mouse dragging works (selection of QLineEdit/item in QListWidget, using scrollbars) What does not work (anywhere) is using the arrow keys. So when a QLineEdit it selected (I can see the highlight of the LE plus I can type in chars) I cannot move back to previous chars using the left arrow key. Also in the QListWidget I cannot scroll inside the content of the LW using the up/down arrow keys. AFAIK I have not set any special options when adding the widgets. I use the QGraphicsScene::addWidget method to add the widget (and not the new QGraphicsProxyWidget, QGraphicsProxyWidget::setWidget and then the QGraphicsScene::addItem method as this seems to break embedding completely such that even mouse interaction is erroneous) What could be wrong ? Thx W -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Jan 15 05:55:41 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 14 Jan 2018 20:55:41 -0800 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: References: Message-ID: <6416171.PvVTrnV4Ii@tjmaciei-mobl1> On Sunday, 14 January 2018 09:49:48 PST Adrien LERAVAT wrote: > Hi all, > > > Before feature freeze, we wanted to challenge the current API for the CoAP > module. I don't think we can make any decisions on CoAP until DTLS support is there. It may influence what the CoAP API looks like. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From timur.pocheptsov at qt.io Mon Jan 15 07:15:15 2018 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Mon, 15 Jan 2018 06:15:15 +0000 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: <6416171.PvVTrnV4Ii@tjmaciei-mobl1> References: , <6416171.PvVTrnV4Ii@tjmaciei-mobl1> Message-ID: > I don't think we can make any decisions on CoAP until DTLS support is there. > It may influence what the CoAP API looks like. Thiago, could you, please, clarify this? They model their Coap client after QNAM and related classes (like QNetworkRequest/Reply pair). As I understand it now - DTLS or not does not affect this API much - they can later add QSslConfiguration/sslErrors signal(s) in their API. Am I missing something? >From client side QDtlsConnection I'm working on is not very different from QSslSocket/QUdpSocket as we have them in Qt now (though it's none of them exactly). Best regards, Timur. ________________________________ From: Development on behalf of Thiago Macieira Sent: Monday, January 15, 2018 5:55:41 AM To: development at qt-project.org Subject: Re: [Development] QtCoap: QNAM-like API or not On Sunday, 14 January 2018 09:49:48 PST Adrien LERAVAT wrote: > Hi all, > > > Before feature freeze, we wanted to challenge the current API for the CoAP > module. I don't think we can make any decisions on CoAP until DTLS support is there. It may influence what the CoAP API looks like. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From pasi.keranen at qt.io Mon Jan 15 09:46:15 2018 From: pasi.keranen at qt.io (=?utf-8?B?UGFzaSBLZXLDpG5lbg==?=) Date: Mon, 15 Jan 2018 08:46:15 +0000 Subject: [Development] Nominating Maintainers of qt3dstudio/qt3dstudio Message-ID: Hi, As the required 15 work days have (ages ago) passed the nominations below for Qt 3D Studio are final. Congratulations to all appointed maintainers! Thank you Lars for updating the https://wiki.qt.io/Maintainers page and gerrit maintainers group. Regards, Pasi From: Development on behalf of Pasi Keränen Date: Thursday, 2 November 2017 at 13.49 To: "development at qt-project.org" Subject: [Development] Nominating Maintainers of qt3dstudio/qt3dstudio Hi all, Those of you who have been following our blog posts or who went to QtCon this year know about the new 3D UI design tool and runtime combination we received as contribution from NVIDIA earlier this year. The tool is now known as Qt 3D Studio and the repositories were opened before Qt WS 2017. For more info check out: http://blog.qt.io/blog/2017/10/11/qt-3d-studio-source-code-pre-release-snapshots-available/ I’d like to name myself (Pasi Keränen) as the maintainer of Qt 3D Studio. I’ve been involved in the project since the early negotiations with NVIDIA and handling the receiving of the contribution from them. All the way to leading the Qt integration work that is still ongoing towards 1.0 release later this month. As Qt 3D Studio is a large piece of work I’d like to also suggest the following persons as maintainers of sub-areas of Qt 3D Studio: Soili Väinämö – Maintainer of UX, ensuring the user experience of the tool and runtime develop going onwards. Soili has been doing excellent work in both converting the look’n’feel of the application to leading UX studies on how to improve the usability of the product from end user point of view. Tomi Korpipää – Maintainer of Editor Application code. Tomi has done great work in handling the bug flow and converting the look’n’feel to more Qt like together with Soili. Antti Määttä – Maintainer of Runtime 1.0 and runtime integration. Antti has long history of working with 3D engine code and has done excellent work in for example prototyping OpenGL ES 2 support in the runtime component of Qt 3D Studio. Laszlo Agocs – Maintainer of Qt 3D based Runtime 2.0. Laszlo has been working on the prototype runtime for some time now and is already looking in to productizing it. Miikka Heikkinen – Maintainer of installer and viewer application. Miikka has been instrumental in getting the installer creation implemented and also has been adding new experimental features to the viewer like image sequence generation. Regards, Pasi Keränen Team lead of TQtC 3D Team, Oulu -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.shaw at qt.io Mon Jan 15 11:09:55 2018 From: andy.shaw at qt.io (Andy Shaw) Date: Mon, 15 Jan 2018 10:09:55 +0000 Subject: [Development] Nominating Joni Poikelin for Approver status Message-ID: <7D30D360-2E62-4ED6-897C-12F63568DF64@qt.io> Hi, I would like to nominate Joni Poikelin for Approver status. He joined The Qt Company over 3 years ago and has consistently contributed to Qt across many modules, fixing a number of issues here and there. His Gerrit dashboard is here: https://codereview.qt-project.org/#/q/owner:%22Joni+Poikelin+%253Cjoni.poikelin%2540qt.io%253E%22+status:merged,n,z Disclaimer: We both work in the same team (support) inside The Qt Company. Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Mon Jan 15 14:52:29 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 15 Jan 2018 13:52:29 +0000 Subject: [Development] Nominating Adam Treat for approver Message-ID: Hi, I would like to nominate Adam for approver status. He has been developing with Qt for more than a decade and has been working on Qt and Qt 3D studio full time for about a year. I fully trust him to review changes thoroughly and reject stuff that looks fishy :) Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Mon Jan 15 14:54:05 2018 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 15 Jan 2018 13:54:05 +0000 Subject: [Development] Nominating Adam Treat for approver In-Reply-To: References: Message-ID: Adam is one of our best. Obvious +1. -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ________________________________ From: Development on behalf of Simon Hausmann Sent: Monday, January 15, 2018 2:52:29 PM To: development at qt-project.org Subject: [Development] Nominating Adam Treat for approver Hi, I would like to nominate Adam for approver status. He has been developing with Qt for more than a decade and has been working on Qt and Qt 3D studio full time for about a year. I fully trust him to review changes thoroughly and reject stuff that looks fishy :) Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at qt.io Mon Jan 15 15:12:06 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Mon, 15 Jan 2018 14:12:06 +0000 Subject: [Development] Mismatch of display resolutions and window sizes in Android applications In-Reply-To: References: Message-ID: This is by design for Qt::AA_EnableHighDpiScaling: you get the logical window size. The physical size can be computed by multiplying with QQuickWindow::effectiveDevicePixelRatio(). For QtLocation it looks like you have to enable high-dpi tiles by setting “osm.mapping.highdpi_tiles" (or a similar option, depending on which tile provider you are using). Morten > On 13 Jan 2018, at 19:27, Denis Shienkov wrote: > > The problem was in Qt::AA_EnableHighDpiScaling option. > > 13.01.2018 19:34, Denis Shienkov пишет: >> Hi all. >> >> Rigth now I faced with the strange issue is that the QML >> window size (screen) does not correspond to the display >> resolution. >> >> For example, I have the "ASUS ZenFone 4 Max ZC554KL" >> smartphone which has display resolution as 1280x720 pixels. >> >> But if I run there the QML application and try to print out >> the ApplicationWindow size, then it is 360x568 or 640x288 >> pixels, depends on orientation. O_o >> >> I have checked the same and on other smartphones, and see >> that there the situation is similar. E.g. for the >> "Samsung Galaxy Ace 3 GT-S7270" with 800x480 display I got >> 320x460 or 533x247 pixels of my ApplicationWindow. >> >> For example if try to use the QtLocation module, then any >> maps looks ugly. >> >> It is very bad surprise for me... Because, seems, now I can >> not write any applications with high resolusion (or, at least >> to operate with a real resolutions from my QML code). >> >> Is there are any tricks to fix it? >> >> PS: Some Android's firmwares (e.g. Cyanogen) allows to change >> the DPI, and with the minimum DPI the ApplicationWindow size >> increases a bit.. But it is not an option anyway. >> >> BR, >> Denis > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From denis.shienkov at gmail.com Mon Jan 15 15:35:51 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Mon, 15 Jan 2018 17:35:51 +0300 Subject: [Development] Mismatch of display resolutions and window sizes in Android applications In-Reply-To: References: Message-ID: Hi, > This is by design for Qt::AA_EnableHighDpiScaling: you get the logical window size. Yes, seems it is. I did not know that. Now, I do not use Qt::AA_EnableHighDpiScaling at all, because I need to operate with a real resolutions. Many thanks, anyway. :) 2018-01-15 17:12 GMT+03:00 Morten Sørvig : > This is by design for Qt::AA_EnableHighDpiScaling: you get the logical > window size. The > physical size can be computed by multiplying with QQuickWindow:: > effectiveDevicePixelRatio(). > > For QtLocation it looks like you have to enable high-dpi tiles by setting > “osm.mapping.highdpi_tiles" > (or a similar option, depending on which tile provider you are using). > > Morten > > > > On 13 Jan 2018, at 19:27, Denis Shienkov > wrote: > > > > The problem was in Qt::AA_EnableHighDpiScaling option. > > > > 13.01.2018 19:34, Denis Shienkov пишет: > >> Hi all. > >> > >> Rigth now I faced with the strange issue is that the QML > >> window size (screen) does not correspond to the display > >> resolution. > >> > >> For example, I have the "ASUS ZenFone 4 Max ZC554KL" > >> smartphone which has display resolution as 1280x720 pixels. > >> > >> But if I run there the QML application and try to print out > >> the ApplicationWindow size, then it is 360x568 or 640x288 > >> pixels, depends on orientation. O_o > >> > >> I have checked the same and on other smartphones, and see > >> that there the situation is similar. E.g. for the > >> "Samsung Galaxy Ace 3 GT-S7270" with 800x480 display I got > >> 320x460 or 533x247 pixels of my ApplicationWindow. > >> > >> For example if try to use the QtLocation module, then any > >> maps looks ugly. > >> > >> It is very bad surprise for me... Because, seems, now I can > >> not write any applications with high resolusion (or, at least > >> to operate with a real resolutions from my QML code). > >> > >> Is there are any tricks to fix it? > >> > >> PS: Some Android's firmwares (e.g. Cyanogen) allows to change > >> the DPI, and with the minimum DPI the ApplicationWindow size > >> increases a bit.. But it is not an option anyway. > >> > >> BR, > >> Denis > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ryan.Chu at qt.io Mon Jan 15 16:25:20 2018 From: Ryan.Chu at qt.io (Ryan Chu) Date: Mon, 15 Jan 2018 15:25:20 +0000 Subject: [Development] Repository request: Qt Notifier Message-ID: Hi all, I'm working on a task supporting "Push Notification" for Qt applications. This feature will be implemented on Android and iOS devices as the first stage. A new module called "Qt Notify" will be created for all platforms. Therefore I request a repository. The first draft of this work was implemented in QtAndroidExtra https://codereview.qt-project.org/#/c/216407/. That would have added its 3rdparty libraries to every application, even if this feature is not used. A standalone module makes it possible for users to include or exclude this feature. Name of the project: Qt Notify Responsible person: Ryan Chu Gerrit user/email: ryan.chu at qt.io Desired repository name: qtnotify Best regards, Ryan Chu -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Mon Jan 15 16:26:33 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 15 Jan 2018 15:26:33 +0000 Subject: [Development] Nominating Adam Treat for approver In-Reply-To: References: Message-ID: <88320596-D14B-447C-AA3E-209D7B9F7EC4@qt.io> I agree. Another +1 from me :) Cheers, Lars On 15 Jan 2018, at 14:54, Jake Petroules > wrote: Adam is one of our best. Obvious +1. -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ________________________________ From: Development > on behalf of Simon Hausmann > Sent: Monday, January 15, 2018 2:52:29 PM To: development at qt-project.org Subject: [Development] Nominating Adam Treat for approver Hi, I would like to nominate Adam for approver status. He has been developing with Qt for more than a decade and has been working on Qt and Qt 3D studio full time for about a year. I fully trust him to review changes thoroughly and reject stuff that looks fishy :) Simon _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Mon Jan 15 16:33:17 2018 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 15 Jan 2018 15:33:17 +0000 Subject: [Development] Repository request: Qt Notifier In-Reply-To: References: Message-ID: “Qt Notifications” (qtnotifications) would be more grammatically in line with the rest of our repository names. -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ________________________________ From: Development on behalf of Ryan Chu Sent: Monday, January 15, 2018 4:25:20 PM To: development at qt-project.org Subject: [Development] Repository request: Qt Notifier Hi all, I'm working on a task supporting "Push Notification" for Qt applications. This feature will be implemented on Android and iOS devices as the first stage. A new module called "Qt Notify" will be created for all platforms. Therefore I request a repository. The first draft of this work was implemented in QtAndroidExtra https://codereview.qt-project.org/#/c/216407/. That would have added its 3rdparty libraries to every application, even if this feature is not used. A standalone module makes it possible for users to include or exclude this feature. Name of the project: Qt Notify Responsible person: Ryan Chu Gerrit user/email: ryan.chu at qt.io Desired repository name: qtnotify Best regards, Ryan Chu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Mon Jan 15 18:01:56 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 15 Jan 2018 17:01:56 +0000 Subject: [Development] Repository request: Qt Notifier In-Reply-To: References: Message-ID: <8F90DBA7-1D30-4A2C-AE09-EC4C0425A9C4@qt.io> > On 15 Jan 2018, at 16:25, Ryan Chu wrote: > > Hi all, > > I'm working on a task supporting "Push Notification" for Qt applications. This feature will be implemented on Android and iOS devices as the first stage. A new module called "Qt Notify" will be created for all platforms. Therefore I request a repository. It will need to have multiple backends right from the beginning. The usual problem on Android is that GCN depends on Google Play Services: it's not a built-in Android feature. So some privacy-respecting free software uses polling solutions instead. But polling solutions tend to drain the battery by using the radio too much (so I have had trouble using such apps). That’s a shame (technically) because GCM manages to get all apps’ notifications over a single connection, which is idle most of the time and thus about as efficient as it can be. Depending on a third-party library is weird though, I agree… So maybe we need two backends already on Android. One using GCN, and one where we try to make a polling solution that is good enough to actually use as an alternative. iOS has APNS. (They pioneered the idea, if memory serves.) On other platforms we could imagine having alternative backends that use standards-based network solutions like XMPP or Matrix (but there are many many others to choose from, potentially). https://puri.sm/shop/librem-5/ will use Matrix, so maybe we should help them support the same API that we come up with, so that Qt apps will be portable to that platform too, when it comes out. (They’ve already said they want to support Qt on it.) Personally I’m interested in trying to use LoRaWAN for such purposes. From bartoszpajewski at gmail.com Mon Jan 15 23:12:32 2018 From: bartoszpajewski at gmail.com (Bartosz Pajewski) Date: Mon, 15 Jan 2018 23:12:32 +0100 Subject: [Development] Qsqldrivers can't loaded in another PC Message-ID: I need a little bit help. After compilation my app and include necessary libraries the app has problem with load drivers included in plugins/sqldrivers. The problem is solved, if I install Qt, and compile project again. How connect dynamicly qsqldrivers into app, to solved problem: "Sql: Drivers not loaded"? -- Regards Bartosz Pajewski www.bartoit.pl -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpham3783 at gmail.com Tue Jan 16 00:01:45 2018 From: tpham3783 at gmail.com (Toan Pham) Date: Mon, 15 Jan 2018 18:01:45 -0500 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <5120988.Mb6HJglHXC@tjmaciei-mobl1> <5244576.1dG1z4Tzuh@tjmaciei-mobl1> <541394F3-306E-4B79-85F1-6C83A966C53B@qt.io> Message-ID: Hi all, I found out what the problem was, as to why qtwebnegineview did not show up on my embedded target (x86 pentium4). The problem was that on my embedded target, I wrote my own version of udev, which did not account for folder creation of /dev/shm when that event came in over netlink-bus. By creating that folder manually (mkdir -p /dev/shm) first, then launch the browser, everything begin to work as expected. So this was just a bug on my udev process. Cheers! On Fri, Jan 12, 2018 at 9:54 AM, Toan Pham wrote: > > I am suspecting that the reason why qtwebengineview did not render because > it could not establish IPC connection to qtwebengineprocess. As seen in > the error below, qtwebengineview aborted when it received unexpected number > of bytes from the IPC initialization call (recvmsg): "unexpected number of > handles". The second error is related to QT not able to allocate more > memory: "FATAL:memory.cc(22)] Out of memory. size=262144". The system had > more than 1.8G of RAM, so I do not see how it is possible. > > > > Reference: Error and stack trace of application: > > >> [13118:13122:0112/095238.425618:ERROR:broker_posix.cc(46)] Received > unexpected number of handles > > My assumption here is that qt could not establish IPC connection with > webengineprocess! > > > > >> [13118:13122:0112/095238.425832:WARNING:client_shared_bitmap_manager.cc(98)] > Browser failed to allocate shared memory > >> [13118:13122:0112/095238.425986:FATAL:memory.cc(22)] Out of memory. > size=262144 > >> #0 0x0000412c4f36 > >> #1 0x0000412c4c5d > >> #2 0x0000412d6c4d > > Obviously, bitmap manager could not allocate memory. The question is > why? system had pretty of RAM. > > > > On Thu, Jan 11, 2018 at 12:49 PM, Toan Pham wrote: > >> >> Thiago, >> >> I managed to get the build completed by performing these steps: >> >> 1. Followed your advise on enabling sse2 because it is a >> hard-requirement. >> 2. Patched libvpx heavily to disable avx+avx2/sse3+ (see attached >> patch) >> 3. Patched libyuv (see attached patch) >> 4. Patched qwebengine/src/core/Makefile.gn_run to launch ninja in >> single thread - otherwise build w/ terminate by Out-Of-Memory manager. >> 5. Used 32bit native linker even though you recommended a 64bit linker. >> >> Step# 2 and 3 were needed because the compiler I was using was optimized >> for pentium4, it wouldn't be able to compile/link-in SIMD instructions >> beyond SSE2. >> >> >> After all that hard work, minimal webengine browser (located at >> qtwebengine/examples/webengine/minimal) did not show anything when I >> launched it (see attached screenshot). I also launched the same browser >> which worked fine under lxc-ubuntu16.04-32bit; but did not show anything >> within the chroot environment of the pentium4 build. OnPageLoad event of >> qtwebengine showed that webpage loaded successfully; so it made me to >> believe that this is an issue with qwebenginewidget. FYI, within the same >> build environment, I was able to run QtWebKit from Qt-5.x a few months >> back. Please help if you know what possibly happened to qwebengineview not >> rendering anything on the view. >> >> >> Thank you, >> >> TP >> >> >> >> >> On Mon, Jan 8, 2018 at 3:21 AM, Lars Knoll wrote: >> >>> > >>> >> For me, it's quite simple: >>> >> No (opensource/commercial) Qt CI = No (opensource/commercial) Qt >>> >> binaries = No (opensource/commercial) support. >>> > >>> > No CI, see above. >>> > No binaries, build from sources. >>> > No support, sorry, I can't comment. >>> >>> Just a quick comment from TQtC’s perspective on this: We do commercially >>> support more platforms than we create binaries for. Linux/32bit is >>> certainly one of those. >>> >>> But as Thiago pointed out, those platforms are not always tested quite >>> as well (unfortunately we can’t possibly test all combinations of OS/CPU >>> architecture/distribution in our CI). >>> >>> Cheers, >>> Lars >>> >>> > >>> >> If you don't build and test on a regular basis, it can break at any >>> >> moment without anyone noticing (and it did happened at least once) >>> > >>> > You're right, but given all the other permutations, we're very likely >>> covered >>> > at a good 99% certainty. >>> > >>> >> PS: In case you think I'm ranting for free here, i would like to say >>> >> (again) that I think Qt is a great piece of (opensource/commercial) >>> >> SW, and big thumb up to anyone behind this, The Qt Project, The Qt >>> >> Company, Intel, ICS, KDAB, KDE, ... and everyone else, individual or >>> >> corporate. >>> > >>> > We're having a constructive conversation, don't worry. >>> > >>> > -- >>> > Thiago Macieira - thiago.macieira (AT) intel.com >>> > Software Architect - Intel Open Source Technology Center >>> > >>> > _______________________________________________ >>> > Development mailing list >>> > Development at qt-project.org >>> > http://lists.qt-project.org/mailman/listinfo/development >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Jan 15 23:55:18 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 15 Jan 2018 14:55:18 -0800 Subject: [Development] Qsqldrivers can't loaded in another PC In-Reply-To: References: Message-ID: <1839576.G3Wn3mqO8c@tjmaciei-mobl1> On Monday, 15 January 2018 14:12:32 PST Bartosz Pajewski wrote: > I need a little bit help. > > After compilation my app and include necessary libraries the app has > problem with load drivers included in plugins/sqldrivers. > The problem is solved, if I install Qt, and compile project again. > > How connect dynamicly qsqldrivers into app, to solved problem: "Sql: > Drivers not loaded"? Please confirm with ldd that the plugin files (the .so files in plugin/ sqldrivers) do not have any "not found" listed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jan 15 20:45:14 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 15 Jan 2018 11:45:14 -0800 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: References: <6416171.PvVTrnV4Ii@tjmaciei-mobl1> Message-ID: <1965723.MYPPyS6Xpj@tjmaciei-mobl1> On Sunday, 14 January 2018 22:15:15 PST Timur Pocheptsov wrote: > > I don't think we can make any decisions on CoAP until DTLS support is > > there. It may influence what the CoAP API looks like. > > Thiago, could you, please, clarify this? Sure. There's no DTLS API. Therefore, CoAP API cannot be implemented. > They model their Coap client after QNAM and related classes (like > QNetworkRequest/Reply pair). > > As I understand it now - DTLS or not does not affect this API much - they > can later You don't know that. Until we know how DTLS will work, we won't know if there's any impact in the front-end API for CoAP. For example, can you use one CoAP server for both encrypted and not encrypted? Multicast and unicast? What's more, we CANNOT release a full CoAP API until it implements DTLS. It's just not acceptable to do so otherwise. Therefore, until there's DTLS, the API is Technology Preview and subject to change. So I don't feel we need to review it yet. I have not spent any time myself. > From client side QDtlsConnection I'm working on is not very different > > from QSslSocket/QUdpSocket as we have them in Qt now (though it's none of > them exactly). We talked about sharing sockets and everything else. There's a lot that may change once you get to the final details. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Maurice.Kalinowski at qt.io Tue Jan 16 08:40:03 2018 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Tue, 16 Jan 2018 07:40:03 +0000 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: <1965723.MYPPyS6Xpj@tjmaciei-mobl1> References: <6416171.PvVTrnV4Ii@tjmaciei-mobl1> <1965723.MYPPyS6Xpj@tjmaciei-mobl1> Message-ID: > > They model their Coap client after QNAM and related classes (like > > QNetworkRequest/Reply pair). > > > > As I understand it now - DTLS or not does not affect this API much - > > they can later > > You don't know that. Until we know how DTLS will work, we won't know if > there's any impact in the front-end API for CoAP. For example, can you use > one CoAP server for both encrypted and not encrypted? Multicast and > unicast? > > What's more, we CANNOT release a full CoAP API until it implements DTLS. > It's just not acceptable to do so otherwise. Therefore, until there's DTLS, the > API is Technology Preview and subject to change. So I don't feel we need to > review it yet. I have not spent any time myself. > [Maurice Kalinowski] I guess having it as Technology Preview for a first release is the usual way to go anyways. That way, the API could still be changed afterwards, but also interested parties could get a first impression and suggest adoptions already, even though DTLS is not available yet. Personally, I do not see those two items (missing DTLS, release TP) conflicting. The only "problem" which might exist, if DTLS takes too long to implement and CoAP would stay for a very long time in TP mode. Maurice From dominik.holland at pelagicore.com Tue Jan 16 10:23:18 2018 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Tue, 16 Jan 2018 10:23:18 +0100 Subject: [Development] Qsqldrivers can't loaded in another PC In-Reply-To: References: Message-ID: Am 01/15/2018 um 11:12 PM schrieb Bartosz Pajewski: > I need a little bit help. > >  After compilation my app and include necessary libraries the app has > problem with load drivers included in plugins/sqldrivers.  > The problem is solved, if I install Qt, and compile project again. I guess what you mean is: You want to include a custom SQL Driver, which is part of your project ? Try the following: Start your application with the env variable set: QT_DEBUG_PLUGINS=1 and check whether the driver you want is listed there and whether it can be loaded at all. If there is a loading problem, use ldd to check whats wrong (what thiago suggested) If your plugin is not listed at all, your plugin path is wrong. By default Qt checks for plugins in its install directory in the plugins folder, but it also checks for plugins in your current work folder. There you need to remove the plugins folder and directly start with the plugin section. E.g. - yourApp - sqldrivers/libmyCustomDriver.so Please also check http://doc.qt.io/qt-5/plugins-howto.html, which explains how Qt finds its plugins. I hope that helps. Dominik From timur.pocheptsov at qt.io Tue Jan 16 11:23:54 2018 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Tue, 16 Jan 2018 10:23:54 +0000 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: References: <6416171.PvVTrnV4Ii@tjmaciei-mobl1> <1965723.MYPPyS6Xpj@tjmaciei-mobl1>, Message-ID: Thiago, thanks for the clarification. Yeah, you have a point, I agree with those reasons though they are more server-related and CoAP module has no one yet. I was also thinking that having a TP status on CoAP module can help to mitigate possible API/design problems/inconsistency. Maurice: > if DTLS takes too long to implement and CoAP would stay for a very long time in TP mode. It should not, but it's too early/too late given feature-freeze in 2 weeks - so it's for 5.12. Could we have CoAP as TP given DTLS will be in 5.12? Best regards, Timur. ________________________________ From: Development on behalf of Maurice Kalinowski Sent: Tuesday, January 16, 2018 8:40:03 AM To: Thiago Macieira; development at qt-project.org Subject: Re: [Development] QtCoap: QNAM-like API or not > > They model their Coap client after QNAM and related classes (like > > QNetworkRequest/Reply pair). > > > > As I understand it now - DTLS or not does not affect this API much - > > they can later > > You don't know that. Until we know how DTLS will work, we won't know if > there's any impact in the front-end API for CoAP. For example, can you use > one CoAP server for both encrypted and not encrypted? Multicast and > unicast? > > What's more, we CANNOT release a full CoAP API until it implements DTLS. > It's just not acceptable to do so otherwise. Therefore, until there's DTLS, the > API is Technology Preview and subject to change. So I don't feel we need to > review it yet. I have not spent any time myself. > [Maurice Kalinowski] I guess having it as Technology Preview for a first release is the usual way to go anyways. That way, the API could still be changed afterwards, but also interested parties could get a first impression and suggest adoptions already, even though DTLS is not available yet. Personally, I do not see those two items (missing DTLS, release TP) conflicting. The only "problem" which might exist, if DTLS takes too long to implement and CoAP would stay for a very long time in TP mode. Maurice _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederik.gladhorn at qt.io Tue Jan 16 11:27:18 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 16 Jan 2018 11:27:18 +0100 Subject: [Development] Nominating Adam Treat for approver In-Reply-To: References: Message-ID: <14177113.mWBg8l05kP@frederik-thinkcentre-m93p> On mandag 15. januar 2018 14.52.29 CET Simon Hausmann wrote: > Hi, > > > I would like to nominate Adam for approver status. He has been developing > with Qt for more than a decade and has been working on Qt and Qt 3D studio > full time for about a year. I fully trust him to review changes thoroughly > and reject stuff that looks fishy :) +1, I've had great discussions with Adam and he knows his way around Qt :) Cheers, Frederik > > > > > Simon From Ryan.Chu at qt.io Tue Jan 16 12:04:57 2018 From: Ryan.Chu at qt.io (Ryan Chu) Date: Tue, 16 Jan 2018 11:04:57 +0000 Subject: [Development] Repository request: Qt Notifications In-Reply-To: References: , Message-ID: Thanks, Jake. It seems to be a better naming. - Revise the module name of my request Hi all, I'm working on a task supporting "Push Notification" for Qt applications. This feature will be implemented on Android and iOS devices as the first stage. A new module called "Qt Notifications" will be created for all platforms. Therefore I request a repository. The first draft of this work was implemented in QtAndroidExtra https://codereview.qt-project.org/#/c/216407/. That would have added its 3rdparty libraries to every application, even if this feature is not used. A standalone module makes it possible for users to include or exclude this feature. Name of the project: Qt Notifications Responsible person: Ryan Chu Gerrit user/email: ryan.chu at qt.io Desired repository name: qtnotifications Best regards, Ryan Chu ________________________________ From: Jake Petroules Sent: Monday, January 15, 2018 4:33 PM To: Ryan Chu; development at qt-project.org Subject: Re: [Development] Repository request: Qt Notifier “Qt Notifications” (qtnotifications) would be more grammatically in line with the rest of our repository names. -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ________________________________ From: Development on behalf of Ryan Chu Sent: Monday, January 15, 2018 4:25:20 PM To: development at qt-project.org Subject: [Development] Repository request: Qt Notifier Hi all, I'm working on a task supporting "Push Notification" for Qt applications. This feature will be implemented on Android and iOS devices as the first stage. A new module called "Qt Notify" will be created for all platforms. Therefore I request a repository. The first draft of this work was implemented in QtAndroidExtra https://codereview.qt-project.org/#/c/216407/. That would have added its 3rdparty libraries to every application, even if this feature is not used. A standalone module makes it possible for users to include or exclude this feature. Name of the project: Qt Notify Responsible person: Ryan Chu Gerrit user/email: ryan.chu at qt.io Desired repository name: qtnotify Best regards, Ryan Chu -------------- next part -------------- An HTML attachment was scrubbed... URL: From kari.oikarinen at qt.io Tue Jan 16 14:49:59 2018 From: kari.oikarinen at qt.io (Kari Oikarinen) Date: Tue, 16 Jan 2018 15:49:59 +0200 Subject: [Development] Repository request: Qt Notifier In-Reply-To: References: Message-ID: On 15.01.2018 17:25, Ryan Chu wrote: > Hi all, > > I'm working on a task supporting "Push Notification" for Qt > applications. This feature will be implemented on Android and iOS > devices as the first stage. A new module called "Qt Notify" will be > created for all platforms. Therefore I request a repository. > This sounds like it overlaps with qtcloudmessaging which also seems to be about push notifications? Or are they actually about something different and I'm mixing things? http://blog.qt.io/blog/2018/01/02/qt-cloud-messaging-api-available-embedded-systems/ -- Kari From Shawn.Rutledge at qt.io Tue Jan 16 15:04:57 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 16 Jan 2018 14:04:57 +0000 Subject: [Development] Repository request: Qt Notifier In-Reply-To: References: Message-ID: > On 16 Jan 2018, at 14:49, Kari Oikarinen wrote: > > > On 15.01.2018 17:25, Ryan Chu wrote: >> Hi all, >> I'm working on a task supporting "Push Notification" for Qt applications. This feature will be implemented on Android and iOS devices as the first stage. A new module called "Qt Notify" will be created for all platforms. Therefore I request a repository. > > This sounds like it overlaps with qtcloudmessaging which also seems > to be about push notifications? Or are they actually about something > different and I'm mixing things? > > http://blog.qt.io/blog/2018/01/02/qt-cloud-messaging-api-available-embedded-systems/ Good catch. So is the API suitable for expanding to mainstream platforms? Also “Qt Notifications” sounds too generic to me, and maybe a bit misleading… we know we need to add support for system/desktop notifications (like the sidebar on macOS, and other UIs on Android and iOS and others) and some work was supposed to be in the pipeline for that at some point - not that it needs its own repo, but this concept might still be the first association for many people. Cloud-based notification is more specific. From annulen at yandex.ru Tue Jan 16 15:18:19 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 16 Jan 2018 17:18:19 +0300 Subject: [Development] Repository request: Qt Notifier In-Reply-To: References: Message-ID: <1538241516112299@web4g.yandex.ru> 16.01.2018, 17:05, "Shawn Rutledge" : >>  On 16 Jan 2018, at 14:49, Kari Oikarinen wrote: >> >>  On 15.01.2018 17:25, Ryan Chu wrote: >>>  Hi all, >>>  I'm working on a task supporting "Push Notification" for Qt applications. This feature will be implemented on Android and iOS devices as the first stage. A new module called "Qt Notify" will be created for all platforms. Therefore I request a repository. >> >>  This sounds like it overlaps with qtcloudmessaging which also seems >>  to be about push notifications? Or are they actually about something >>  different and I'm mixing things? >> >>  http://blog.qt.io/blog/2018/01/02/qt-cloud-messaging-api-available-embedded-systems/ > > Good catch. So is the API suitable for expanding to mainstream platforms? > > Also “Qt Notifications” sounds too generic to me, and maybe a bit misleading… we know we need to add support for system/desktop notifications (like the sidebar on macOS, and other UIs on Android and iOS and others) and some work was supposed to be in the pipeline for that at some point - not that it needs its own repo, but this concept might still be the first association for many people. Cloud-based notification is more specific. Is cloud aspect so principal? Can there be "non-cloud" backend which just uses persistent HTTP connection, e.g. with nginx-push-stream-module on the server side? https://github.com/wandenberg/nginx-push-stream-module > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From Shawn.Rutledge at qt.io Tue Jan 16 15:46:29 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 16 Jan 2018 14:46:29 +0000 Subject: [Development] Repository request: Qt Notifier In-Reply-To: <1538241516112299@web4g.yandex.ru> References: <1538241516112299@web4g.yandex.ru> Message-ID: > On 16 Jan 2018, at 15:18, Konstantin Tokarev wrote: > > Is cloud aspect so principal? Can there be "non-cloud" backend which just uses persistent > HTTP connection, e.g. with nginx-push-stream-module on the server side? > > https://github.com/wandenberg/nginx-push-stream-module An HTTP server is usually in the cloud too, isn’t it? unless it’s only on your LAN and not Internet-accessible. “Notification” is a pretty generic term: could mean a Qt signal, an email, a jumping icon in your dock, some other aspect of desktop or application UI, a message from an IRC bot, a letter in the mail, … From annulen at yandex.ru Tue Jan 16 15:55:18 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 16 Jan 2018 17:55:18 +0300 Subject: [Development] Repository request: Qt Notifier In-Reply-To: References: <1538241516112299@web4g.yandex.ru> Message-ID: <5788911516114518@web56g.yandex.ru> 16.01.2018, 17:46, "Shawn Rutledge" : >>  On 16 Jan 2018, at 15:18, Konstantin Tokarev wrote: >> >>  Is cloud aspect so principal? Can there be "non-cloud" backend which just uses persistent >>  HTTP connection, e.g. with nginx-push-stream-module on the server side? >> >>  https://github.com/wandenberg/nginx-push-stream-module > > An HTTP server is usually in the cloud too, isn’t it? unless it’s only on your LAN and not Internet-accessible. Or on my own server. Or Qt application on other device. > > “Notification” is a pretty generic term: could mean a Qt signal, an email, a jumping icon in your dock, some other aspect of desktop or application UI, a message from an IRC bot, a letter in the mail, … > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From Uwe.Rathmann at tigertal.de Tue Jan 16 16:20:54 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Tue, 16 Jan 2018 15:20:54 +0000 (UTC) Subject: [Development] Undeprecating QString::null Message-ID: Hi all, I received a bug report concerning a header of the Qwt library ( http:// qwt.sf.net ), that is using the deprecated QString::null. Sure this is only a warning, but it is obviously something where Qwt users get irritated as they can't fix code of a 3rd party header. The offending line looks like this: QwtText( const QString & = QString::null, ... ); So my first question would be, what is wrong about using QString:null and why using QString() is better. My second question then would be if this is also for Qt4 ( Qwt 6.1.2 supports all versions >= Qt 4.4 ) and older versions of C++ and compilers. To be honest I don't want to create a new ( + binary incompatible ) version of Qwt and/or add even more version depending #ifdefs, as long as there is no good reason. ciao, Uwe From olivier at woboq.com Tue Jan 16 16:47:57 2018 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 16 Jan 2018 16:47:57 +0100 Subject: [Development] Undeprecating QString::null In-Reply-To: References: Message-ID: <25297410.iF1qyPYTYD@maurice> Am Dienstag, 16. Januar 2018, 16:20:54 CET schrieb Uwe Rathmann: > Hi all, > > I received a bug report concerning a header of the Qwt library ( http:// > qwt.sf.net ), that is using the deprecated QString::null. > > Sure this is only a warning, but it is obviously something where Qwt > users get irritated as they can't fix code of a 3rd party header. > > The offending line looks like this: > > QwtText( const QString & = QString::null, ... ); > > So my first question would be, what is wrong about using QString:null and > why using QString() is better. My second question then would be if this > is also for Qt4 ( Qwt 6.1.2 supports all versions >= Qt 4.4 ) and older > versions of C++ and compilers. > > To be honest I don't want to create a new ( + binary incompatible ) > version of Qwt and/or add even more version depending #ifdefs, as long as > there is no good reason. QString::null is a leftover of Qt3 and was already deprecated in Qt 4.0 There was just some forgotten remaining compatibility code that was only recently marked as QT_DEPRECATED. Just change your code to use "= QString()", no #ifdef necessary. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From Uwe.Rathmann at tigertal.de Tue Jan 16 17:16:07 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Tue, 16 Jan 2018 16:16:07 +0000 (UTC) Subject: [Development] Undeprecating QString::null References: <25297410.iF1qyPYTYD@maurice> Message-ID: On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote: > Just change your code to use "= QString()", no #ifdef necessary. The "just change" introduces a binary incompatibility - right ? Please be aware, that Qwt is part of almost any Linux distro - according to sourceforge it has more than 1000 additional downloads every week since many years. All distro maintainers would not only have to upgrade the Qwt packages, but also all packages depending on it - users would have to rebuild. Considering the strict compatibility rules you have for Qt you will understand, that this is nothing I would like to do easily. But could you please comment on why this change is an improvement - beyond getting rid of 3-4 lines in qstring.h ? Thanks, Uwe From annulen at yandex.ru Tue Jan 16 17:22:54 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 16 Jan 2018 19:22:54 +0300 Subject: [Development] Undeprecating QString::null In-Reply-To: References: <25297410.iF1qyPYTYD@maurice> Message-ID: <6007311516119774@web56g.yandex.ru> 16.01.2018, 19:18, "Uwe Rathmann" : > On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote: > >>  Just change your code to use "= QString()", no #ifdef necessary. > > The "just change" introduces a binary incompatibility - right ? > > Please be aware, that Qwt is part of almost any Linux distro - according > to sourceforge it has more than 1000 additional downloads every week > since many years. > > All distro maintainers would not only have to upgrade the Qwt packages, > but also all packages depending on it - users would have to rebuild. However, it seems like amount of reverse dependencies of Qwt is rather moderate, e.g. in Ubuntu I see libqwt6:i386 zygrib simon qsapecng qgis nlkt libqwt-dev libqgis-gui2.0.1 > > Considering the strict compatibility rules you have for Qt you will > understand, that this is nothing I would like to do easily. > > But could you please comment on why this change is an improvement - > beyond getting rid of 3-4 lines in qstring.h ? Because having redundancies in API is bad maybe? > > Thanks, > Uwe > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From nassian at bitshift-dynamics.com Tue Jan 16 17:26:51 2018 From: nassian at bitshift-dynamics.com (Alexander Nassian) Date: Tue, 16 Jan 2018 17:26:51 +0100 Subject: [Development] Undeprecating QString::null In-Reply-To: References: <25297410.iF1qyPYTYD@maurice> Message-ID: <4AD0371A-7EDE-4722-8BDC-66D571D16A3B@bitshift-dynamics.com> Deprecated since Qt4 (so it survived already two versions that were allowed to break binary compatibility) means that you had 12 (twelve) years to do the migration. How long should it be maintained? And again, it also could have been removed in Qt4 or 5. > Am 16.01.2018 um 17:16 schrieb Uwe Rathmann : > > On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote: > >> Just change your code to use "= QString()", no #ifdef necessary. > > The "just change" introduces a binary incompatibility - right ? > > Please be aware, that Qwt is part of almost any Linux distro - according > to sourceforge it has more than 1000 additional downloads every week > since many years. > > All distro maintainers would not only have to upgrade the Qwt packages, > but also all packages depending on it - users would have to rebuild. > > Considering the strict compatibility rules you have for Qt you will > understand, that this is nothing I would like to do easily. > > But could you please comment on why this change is an improvement - > beyond getting rid of 3-4 lines in qstring.h ? > > Thanks, > Uwe > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- -- bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: info at bitshift-dynamics.com Technischer Support: support at bitshift-dynamics.com Buchhaltung: invoice at bitshift-dynamics.com From jeanmichael.celerier at gmail.com Tue Jan 16 17:35:26 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 16 Jan 2018 17:35:26 +0100 Subject: [Development] Undeprecating QString::null In-Reply-To: <6007311516119774@web56g.yandex.ru> References: <25297410.iF1qyPYTYD@maurice> <6007311516119774@web56g.yandex.ru> Message-ID: > The "just change" introduces a binary incompatibility - right ? I don't think it does: the QString is constructed on the caller's side anyways and your function is always passed a QString object; if you had an app that linked to qwt and didn't recompile it will just keep calling QString::null() from its side and pass the resulting object to your function. Best, Jean-Michaël On Tue, Jan 16, 2018 at 5:22 PM, Konstantin Tokarev wrote: > > > 16.01.2018, 19:18, "Uwe Rathmann" : > > On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote: > > > >> Just change your code to use "= QString()", no #ifdef necessary. > > > > The "just change" introduces a binary incompatibility - right ? > > > > Please be aware, that Qwt is part of almost any Linux distro - according > > to sourceforge it has more than 1000 additional downloads every week > > since many years. > > > > All distro maintainers would not only have to upgrade the Qwt packages, > > but also all packages depending on it - users would have to rebuild. > > However, it seems like amount of reverse dependencies of Qwt is rather > moderate, e.g. in Ubuntu I see > > libqwt6:i386 > zygrib > simon > qsapecng > qgis > nlkt > libqwt-dev > libqgis-gui2.0.1 > > > > > > Considering the strict compatibility rules you have for Qt you will > > understand, that this is nothing I would like to do easily. > > > > But could you please comment on why this change is an improvement - > > beyond getting rid of 3-4 lines in qstring.h ? > > Because having redundancies in API is bad maybe? > > > > > Thanks, > > Uwe > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eike.Ziller at qt.io Tue Jan 16 17:38:15 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Tue, 16 Jan 2018 16:38:15 +0000 Subject: [Development] Undeprecating QString::null In-Reply-To: References: <25297410.iF1qyPYTYD@maurice> Message-ID: > On Jan 16, 2018, at 17:16, Uwe Rathmann wrote: > > On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote: > >> Just change your code to use "= QString()", no #ifdef necessary. > > The "just change" introduces a binary incompatibility - right ? I don’t see why that would be the case, the function signature doesn’t change. Br, Eike > > Please be aware, that Qwt is part of almost any Linux distro - according > to sourceforge it has more than 1000 additional downloads every week > since many years. > > All distro maintainers would not only have to upgrade the Qwt packages, > but also all packages depending on it - users would have to rebuild. > > Considering the strict compatibility rules you have for Qt you will > understand, that this is nothing I would like to do easily. > > But could you please comment on why this change is an improvement - > beyond getting rid of 3-4 lines in qstring.h ? > > Thanks, > Uwe > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From ritt.ks at gmail.com Tue Jan 16 17:41:40 2018 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Tue, 16 Jan 2018 20:41:40 +0400 Subject: [Development] Undeprecating QString::null In-Reply-To: References: <25297410.iF1qyPYTYD@maurice> <6007311516119774@web56g.yandex.ru> Message-ID: changing the parameter's default value *is* binary compatible. Regards, Konstantin 2018-01-16 20:35 GMT+04:00 Jean-Michaël Celerier < jeanmichael.celerier at gmail.com>: > > The "just change" introduces a binary incompatibility - right ? > > I don't think it does: the QString is constructed on the caller's side > anyways and your function is always passed a QString object; > if you had an app that linked to qwt and didn't recompile it will just > keep calling QString::null() from its side and pass the resulting object to > your function. > > Best, > Jean-Michaël > > On Tue, Jan 16, 2018 at 5:22 PM, Konstantin Tokarev > wrote: > >> >> >> 16.01.2018, 19:18, "Uwe Rathmann" : >> > On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote: >> > >> >> Just change your code to use "= QString()", no #ifdef necessary. >> > >> > The "just change" introduces a binary incompatibility - right ? >> > >> > Please be aware, that Qwt is part of almost any Linux distro - according >> > to sourceforge it has more than 1000 additional downloads every week >> > since many years. >> > >> > All distro maintainers would not only have to upgrade the Qwt packages, >> > but also all packages depending on it - users would have to rebuild. >> >> However, it seems like amount of reverse dependencies of Qwt is rather >> moderate, e.g. in Ubuntu I see >> >> libqwt6:i386 >> zygrib >> simon >> qsapecng >> qgis >> nlkt >> libqwt-dev >> libqgis-gui2.0.1 >> >> >> > >> > Considering the strict compatibility rules you have for Qt you will >> > understand, that this is nothing I would like to do easily. >> > >> > But could you please comment on why this change is an improvement - >> > beyond getting rid of 3-4 lines in qstring.h ? >> >> Because having redundancies in API is bad maybe? >> >> > >> > Thanks, >> > Uwe >> > >> > _______________________________________________ >> > Development mailing list >> > Development at qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Regards, >> Konstantin >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Tue Jan 16 17:46:09 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Tue, 16 Jan 2018 16:46:09 +0000 (UTC) Subject: [Development] Undeprecating QString::null References: <25297410.iF1qyPYTYD@maurice> <4AD0371A-7EDE-4722-8BDC-66D571D16A3B@bitshift-dynamics.com> Message-ID: On Tue, 16 Jan 2018 17:26:51 +0100, Alexander Nassian wrote: > Deprecated since Qt4 ... According to qstring.h: #if QT_DEPRECATED_SINCE(5, 9) ... #endif But come this is not about me and if I missed, that an API has been declared as deprecated. It is about what to best in the current situation. Uwe From Lorenz.Esch at tu-ilmenau.de Tue Jan 16 17:49:05 2018 From: Lorenz.Esch at tu-ilmenau.de (Esch Lorenz TU Ilmenau) Date: Tue, 16 Jan 2018 16:49:05 +0000 Subject: [Development] Qt3D: Correct way of using QBuffer and compute shader Message-ID: Dear Qt Community, I am writing my first application using a compute shader based on Qt3D in C++. My question: What is the correct way of updating the data needed by the compute shader during run-time? This is what I tried so far: I create a QBuffer object (in form of a QPointer) and fill it with data. The pointer is kept as a member in a class. I set the buffer via .data() to a QVariant and set it as data to the corresponding QParameter. The following is a code snippet showing the basic idea: QByteArray interpolationBufferData = buildInterpolationMatrixBuffer(matInterpolationMatrix); //Builds the data array from a large Eigen Matrix m_pInterpolationMatBuffer = new Qt3DRender::QBuffer(Qt3DRender::QBuffer::ShaderStorageBuffer); m_pInterpolationMatBuffer->setData(interpolationBufferData); m_pParameter ->setValue(QVariant::fromValue(m_pInterpolationMatBuffer.data()), QStringLiteral("InterpolationMat")); m_pInterpolationMatBuffer->setData(interpolationBufferData); Everything works fine until here. The visualization is doing what it is supposed to do and the compute shader works fine. After a new input matrix arrives I create a new QByteArray and try to load to the QBuffer object via updateData (I also tried setData). Once I try to update the data in the QBuffer the application crashes. QByteArray interpolationBufferData = buildInterpolationMatrixBuffer(matInterpolationMatrix); //Builds the data array from an incoming Eigen Matrix m_pInterpolationMatBuffer->updateData(0, interpolationBufferData); Am I missing something? Is there a better way to update data used by the compute shader? Should I pay attention to the usage type (StreamDraw, StaticDraw, etc.)? Also, is the complete QByteArray internally copied to the GPU when setting only the pointer to the QVariant? Maybe I should create a new buffer every time I receive new data? Questions over questions 😊 Best from Germany and many thanks, Lorenz -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Tue Jan 16 17:54:43 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 16 Jan 2018 17:54:43 +0100 Subject: [Development] Undeprecating QString::null In-Reply-To: References: Message-ID: <3ede1739-8e39-64a8-6de2-4c1fe24c5481@kdab.com> Il 16/01/2018 16:20, Uwe Rathmann ha scritto: > Sure this is only a warning, but it is obviously something where Qwt > users get irritated as they can't fix code of a 3rd party header. Changing to QString() is BC, as explained, so just do that. Note that this is actually a buildsystem issue: headers of 3rd party libraries should be included under -isystem, not -I, to disable warnings in their headers. Hope this helps, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From nassian at bitshift-dynamics.com Tue Jan 16 17:59:28 2018 From: nassian at bitshift-dynamics.com (Alexander Nassian) Date: Tue, 16 Jan 2018 17:59:28 +0100 Subject: [Development] Undeprecating QString::null In-Reply-To: References: <25297410.iF1qyPYTYD@maurice> <4AD0371A-7EDE-4722-8BDC-66D571D16A3B@bitshift-dynamics.com> Message-ID: <1DBE41A7-A15D-4D55-B1DC-4CA67205AFC0@bitshift-dynamics.com> No it isn‘t about you. But your message suggested you blame it on Qt project ;) Anyway, default values are not part of a functions signature and don’t break binary compatibility. Beste Grüße / Best regards, Alexander Nassian > Am 16.01.2018 um 17:46 schrieb Uwe Rathmann : > >> On Tue, 16 Jan 2018 17:26:51 +0100, Alexander Nassian wrote: >> >> Deprecated since Qt4 ... > > According to qstring.h: > > #if QT_DEPRECATED_SINCE(5, 9) > ... > #endif > > But come this is not about me and if I missed, that an API has been > declared as deprecated. It is about what to best in the current situation. > > Uwe > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: info at bitshift-dynamics.com Technischer Support: support at bitshift-dynamics.com Buchhaltung: invoice at bitshift-dynamics.com From Uwe.Rathmann at tigertal.de Tue Jan 16 18:08:09 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Tue, 16 Jan 2018 17:08:09 +0000 (UTC) Subject: [Development] Undeprecating QString::null References: <3ede1739-8e39-64a8-6de2-4c1fe24c5481@kdab.com> Message-ID: On Tue, 16 Jan 2018 17:54:43 +0100, Giuseppe D'Angelo wrote: > headers of 3rd party libraries > should be included under -isystem, not -I, to disable warnings in their > headers. Yes as there seems to be no BC break ( thanks to all correcting me, I should have a deeper look at the code before ) this is a reasonable recommendation - at least for platforms, where the option is available - I can give my users for now. Sorry for the noise, Uwe From jhihn at gmx.com Tue Jan 16 18:22:34 2018 From: jhihn at gmx.com (Jason H) Date: Tue, 16 Jan 2018 18:22:34 +0100 Subject: [Development] Repository request: Qt Notifier In-Reply-To: <1538241516112299@web4g.yandex.ru> References: <1538241516112299@web4g.yandex.ru> Message-ID: > Sent: Tuesday, January 16, 2018 at 9:18 AM > From: "Konstantin Tokarev" > To: "Shawn Rutledge" , "development at qt-project.org" > Subject: Re: [Development] Repository request: Qt Notifier > > > > 16.01.2018, 17:05, "Shawn Rutledge" : > >>  On 16 Jan 2018, at 14:49, Kari Oikarinen wrote: > >> > >>  On 15.01.2018 17:25, Ryan Chu wrote: > >>>  Hi all, > >>>  I'm working on a task supporting "Push Notification" for Qt applications. This feature will be implemented on Android and iOS devices as the first stage. A new module called "Qt Notify" will be created for all platforms. Therefore I request a repository. > >> > >>  This sounds like it overlaps with qtcloudmessaging which also seems > >>  to be about push notifications? Or are they actually about something > >>  different and I'm mixing things? > >> > >>  http://blog.qt.io/blog/2018/01/02/qt-cloud-messaging-api-available-embedded-systems/ > > > > Good catch. So is the API suitable for expanding to mainstream platforms? > > > > Also “Qt Notifications” sounds too generic to me, and maybe a bit misleading… we know we need to add support for system/desktop notifications (like the sidebar on macOS, and other UIs on Android and iOS and others) and some work was supposed to be in the pipeline for that at some point - not that it needs its own repo, but this concept might still be the first association for many people. Cloud-based notification is more specific. > > Is cloud aspect so principal? Can there be "non-cloud" backend which just uses persistent > HTTP connection, e.g. with nginx-push-stream-module on the server side? > Sure, actually no connection at all is needed. As someone who made android apps with local and push notifications, I can tell you that there are a few differences between local and push notifications. Notes on local (non-cloud) notifications: - Toner low - Network disconnected - Calendar alarm or local timer event - Processing completed (local worker) - No special permission required on mobile - Can invoke the application on receipt Notes on push notifications: - Processing completed (remote job) - Someone messaged you - Can come from a variety of backends (Firebase (Google), APNS (Apple), Amazon, V-Play, etc) - Permissions are/may be required on mobile - Will be stored & forwarded by the provider - Can invoke the application on receipt - Not all providers use the same schema on all platforms (Firebase schema is different on iOS vs Android) Notifications were once a mobile phenomenon, but have extended to include all the major Desktop environents. I would hope that whatever Qt provides would be structured in such a way that remote notifications use the same as local notifications, and that we can just plug in whatever backends we are using. From kevin.kofler at chello.at Tue Jan 16 18:38:48 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 16 Jan 2018 18:38:48 +0100 Subject: [Development] Undeprecating QString::null References: Message-ID: Uwe Rathmann wrote: > So my first question would be, what is wrong about using QString:null and > why using QString() is better. My second question then would be if this > is also for Qt4 ( Qwt 6.1.2 supports all versions >= Qt 4.4 ) and older > versions of C++ and compilers. A long long time ago, QString::null used to be a static instance of QString(). This was more efficient than QString() in a context like this one where a const QString & is needed, but less efficient in many contexts where people (ab)used it, e.g.: QString foo = QString::null; which should really be just: QString foo; Thus, now, QString::null is just a static instance of an empty structure, and converting that structure to QString is the same as QString(), so there is no longer any performance benefit from using QString::null. This was already the case in Qt 4. Even Qt 3.3.8b already had that change. So just use QString(), or define your own static instance of it if you really want to microoptimize it that much. Kevin Kofler From Uwe.Rathmann at tigertal.de Tue Jan 16 19:28:27 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Tue, 16 Jan 2018 18:28:27 +0000 (UTC) Subject: [Development] Undeprecating QString::null References: Message-ID: On Tue, 16 Jan 2018 18:38:48 +0100, Kevin Kofler wrote: > So just use QString(), or define your own static instance of it if you > really want to microoptimize it that much. No it is simply that the first version of Qwt was for Qt 1.2 ( before QString even existed ) and during a history of almost 20 years there are leftovers. I had missed the point, when the static instance had been replaced - that's why I was erroneously concerned about BC breaks. Uwe From samuel.gaist at edeltech.ch Tue Jan 16 21:09:56 2018 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Tue, 16 Jan 2018 21:09:56 +0100 Subject: [Development] Repository request: Qt Notifier In-Reply-To: References: Message-ID: <709FE09A-2A0F-49B3-8DC8-46A1C436CE6D@edeltech.ch> > On 16 Jan 2018, at 15:04, Shawn Rutledge wrote: > > >> On 16 Jan 2018, at 14:49, Kari Oikarinen wrote: >> >> >> On 15.01.2018 17:25, Ryan Chu wrote: >>> Hi all, >>> I'm working on a task supporting "Push Notification" for Qt applications. This feature will be implemented on Android and iOS devices as the first stage. A new module called "Qt Notify" will be created for all platforms. Therefore I request a repository. >> >> This sounds like it overlaps with qtcloudmessaging which also seems >> to be about push notifications? Or are they actually about something >> different and I'm mixing things? >> >> http://blog.qt.io/blog/2018/01/02/qt-cloud-messaging-api-available-embedded-systems/ > > Good catch. So is the API suitable for expanding to mainstream platforms? > > Also “Qt Notifications” sounds too generic to me, and maybe a bit misleading… we know we need to add support for system/desktop notifications (like the sidebar on macOS, and other UIs on Android and iOS and others) and some work was supposed to be in the pipeline for that at some point - not that it needs its own repo, but this concept might still be the first association for many people. Cloud-based notification is more specific. Hi, The work you are thinking about is likely this one: https://codereview.qt-project.org/#/c/166456/. I’d be happy to reactivate it. Cheers Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From alex at vikingsoftware.com Tue Jan 16 22:49:29 2018 From: alex at vikingsoftware.com (Alejandro Exojo) Date: Tue, 16 Jan 2018 22:49:29 +0100 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: References: Message-ID: <5925207.XClqdvNNj2@walt> On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote: > In that case, the QCoapReply life is managed with a > QSharedPointer in the request. > > QCoapRequest does not inherit from QObject. Anyone sees a problem with this > approach? The API sounds interesting, but it's a departure of what we are used in QNAM. What happened to the idea of using a setter on the manager, for making the replies self-delete if wanted? (it was mentioned on the QtCS) That had the advantage that can be added to QNAM as well, so both can end up having a similar API. -- Viking Software, Qt and C++ developers for hire http://www.vikingsoftware.com From ari.salmi at snowgrains.com Wed Jan 17 09:41:32 2018 From: ari.salmi at snowgrains.com (Ari Salmi) Date: Wed, 17 Jan 2018 10:41:32 +0200 Subject: [Development] Repository request: Qt Notifier In-Reply-To: <709FE09A-2A0F-49B3-8DC8-46A1C436CE6D@edeltech.ch> References: <709FE09A-2A0F-49B3-8DC8-46A1C436CE6D@edeltech.ch> Message-ID: Hi there, Thanks for asking: >Ari: can you give (or point us to, if it's already written up) an  >over-view of what's supported, on which platforms, and how far the API,  >seen by Qt code using it, is independent of choice of back-end ?  >How far is it dependent on the Kaltiot service ? What is that ?  >The blog post looks promising, at least :-)  The purpose of the Qt Cloud messaging is to provide possibility to wrap platform specific push notification backend or implement full cross platform with Qt’s own components (e.g. against customer’s own backend). API itself is independent of the backend - developer can choose which one to use for his/her product. Or can implement (and contribute) own backend as well. Wrappers at the moment in QtCloudMessaging are: - Firebase Cloud Messaging support for Android and iOS - And Kaltiot embedded devices notification services. Kaltiot SDK also works on desktops so  Kaltiot is a embedded notification service provider which is capable of handling, managing production level amount of devices (I guess there are no limit when negotiated with Kaltiot). Currently Kaltiot wrapper includes push notification service parts against their SDK.  Going forward, next steps on this are to fine tune the SDK API. And find more fluent way to configure wrapped SDKs to make first time usage easier (currently needs few env. variables to point e.g. to downloaded Firebase SDK etc.) as it will help to implement more platform specific SDKs as backend. All the help on these are appreciated ! Current usage: There are few customers using this wrapper already in their mobile app production against Firebase.  Also Kaltiot customer base is now growing due this.  So I guess time used for creating this has been worthwhile and gives more opportunities to Qt be on the chosen platform for device & app development :) Br, Ari Päällä 16 January 2018 klo 22.10.09, Samuel Gaist (samuel.gaist at edeltech.ch) kirjoitti: > On 16 Jan 2018, at 15:04, Shawn Rutledge wrote: > > >> On 16 Jan 2018, at 14:49, Kari Oikarinen wrote: >> >> >> On 15.01.2018 17:25, Ryan Chu wrote: >>> Hi all, >>> I'm working on a task supporting "Push Notification" for Qt applications. This feature will be implemented on Android and iOS devices as the first stage. A new module called "Qt Notify" will be created for all platforms. Therefore I request a repository. >> >> This sounds like it overlaps with qtcloudmessaging which also seems >> to be about push notifications? Or are they actually about something >> different and I'm mixing things? >> >> http://blog.qt.io/blog/2018/01/02/qt-cloud-messaging-api-available-embedded-systems/ > > Good catch. So is the API suitable for expanding to mainstream platforms? > > Also “Qt Notifications” sounds too generic to me, and maybe a bit misleading… we know we need to add support for system/desktop notifications (like the sidebar on macOS, and other UIs on Android and iOS and others) and some work was supposed to be in the pipeline for that at some point - not that it needs its own repo, but this concept might still be the first association for many people. Cloud-based notification is more specific. Hi, The work you are thinking about is likely this one: https://codereview.qt-project.org/#/c/166456/. I’d be happy to reactivate it. Cheers Samuel _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Wed Jan 17 15:41:08 2018 From: jhihn at gmx.com (Jason H) Date: Wed, 17 Jan 2018 15:41:08 +0100 Subject: [Development] Repository request: Qt Notifier In-Reply-To: References: <709FE09A-2A0F-49B3-8DC8-46A1C436CE6D@edeltech.ch> Message-ID: An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Jan 17 18:12:35 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Jan 2018 09:12:35 -0800 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: References: <1965723.MYPPyS6Xpj@tjmaciei-mobl1> Message-ID: <1619951.uyHpAGVhCi@tjmaciei-mobl1> On Monday, 15 January 2018 23:40:03 PST Maurice Kalinowski wrote: > Personally, I do not see those two items (missing DTLS, release TP) > conflicting. The only "problem" which might exist, if DTLS takes too long > to implement and CoAP would stay for a very long time in TP mode. I don't see a way out, though I'm hoping it won't be the case. "No security" is just not acceptable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jan 17 18:18:05 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Jan 2018 09:18:05 -0800 Subject: [Development] Undeprecating QString::null In-Reply-To: References: Message-ID: <4438606.Q6Vv1d8keg@tjmaciei-mobl1> On Tuesday, 16 January 2018 10:28:27 PST Uwe Rathmann wrote: > On Tue, 16 Jan 2018 18:38:48 +0100, Kevin Kofler wrote: > > So just use QString(), or define your own static instance of it if you > > really want to microoptimize it that much. > > No it is simply that the first version of Qwt was for Qt 1.2 ( before > QString even existed ) and during a history of almost 20 years there are > leftovers. Nitpick: QString existed in Qt 1.2, it just wasn't the QString we know. It was actually the predecessor to Qt 2's QCString, which in Qt 4 became Q3CString and was deprecated by QByteArray. > I had missed the point, when the static instance had been replaced - > that's why I was erroneously concerned about BC breaks. There's still static data, but unlike the Qt 1 solution, it's not an instance of QString but just of the shared null data. Since Qt 5, it's also shared with QVector and QByteArray. That's why the constructor is just as efficient. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jan 17 18:12:35 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Jan 2018 09:12:35 -0800 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: References: <1965723.MYPPyS6Xpj@tjmaciei-mobl1> Message-ID: <1619951.uyHpAGVhCi@tjmaciei-mobl1> On Monday, 15 January 2018 23:40:03 PST Maurice Kalinowski wrote: > Personally, I do not see those two items (missing DTLS, release TP) > conflicting. The only "problem" which might exist, if DTLS takes too long > to implement and CoAP would stay for a very long time in TP mode. I don't see a way out, though I'm hoping it won't be the case. "No security" is just not acceptable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jan 17 18:12:35 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Jan 2018 09:12:35 -0800 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: References: <1965723.MYPPyS6Xpj@tjmaciei-mobl1> Message-ID: <1619951.uyHpAGVhCi@tjmaciei-mobl1> On Monday, 15 January 2018 23:40:03 PST Maurice Kalinowski wrote: > Personally, I do not see those two items (missing DTLS, release TP) > conflicting. The only "problem" which might exist, if DTLS takes too long > to implement and CoAP would stay for a very long time in TP mode. I don't see a way out, though I'm hoping it won't be the case. "No security" is just not acceptable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jan 17 22:25:53 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Jan 2018 13:25:53 -0800 Subject: [Development] API review request: CBOR Stream reader and writer Message-ID: <2363292.KCnvKgr5nM@tjmaciei-mobl1> Hello I finished writing the documentation for the two basic classes for CBOR. You can find them in reviews https://codereview.qt-project.org/107465 https://codereview.qt-project.org/107466 Please review. I will take a couple more days writing the docs for QCbor{Value,Map,Array} and then I'll upload that too. I'm also interested in what I could write as an example. Please send suggestions. My current idea is a command-line tool that converts between serialisation formats: * CBOR * CBOR diagnostic notation (output only, since I won't write the parser) * JSON * XML * Qt binary JSON * Plain QDataStream (output only, since it's not self-describing) * QDataStream-serialised QVariant (is self-describing) Though, because of the conversions, this example is ideal for QCborValue, not the stream reader and writer. Another idea is to update the network-chat example to use CBOR instead of its plaintext protocol. In this one, I could use the stream reader and writer. This example is a perfect candidate to have a CoAP version in the future too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jan 18 04:22:36 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Jan 2018 19:22:36 -0800 Subject: [Development] API review request: CBOR Stream reader and writer In-Reply-To: <2363292.KCnvKgr5nM@tjmaciei-mobl1> References: <2363292.KCnvKgr5nM@tjmaciei-mobl1> Message-ID: <1599614.N3b9CUZJvf@tjmaciei-mobl1> On Wednesday, 17 January 2018 13:25:53 PST Thiago Macieira wrote: > Another idea is to update the network-chat example to use CBOR instead of > its plaintext protocol. In this one, I could use the stream reader and > writer. This example is a perfect candidate to have a CoAP version in the > future too. I've done this then: https://codereview.qt-project.org/217078 https://codereview.qt-project.org/217079 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From dominik.holland at pelagicore.com Thu Jan 18 09:51:18 2018 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Thu, 18 Jan 2018 09:51:18 +0100 Subject: [Development] API review request: CBOR Stream reader and writer In-Reply-To: <1599614.N3b9CUZJvf@tjmaciei-mobl1> References: <2363292.KCnvKgr5nM@tjmaciei-mobl1> <1599614.N3b9CUZJvf@tjmaciei-mobl1> Message-ID: Am 01/18/2018 um 04:22 AM schrieb Thiago Macieira: > On Wednesday, 17 January 2018 13:25:53 PST Thiago Macieira wrote: >> Another idea is to update the network-chat example to use CBOR instead of >> its plaintext protocol. In this one, I could use the stream reader and >> writer. This example is a perfect candidate to have a CoAP version in the >> future too. > I've done this then: > https://codereview.qt-project.org/217078 > https://codereview.qt-project.org/217079 > Why not keep the existing example and do a network-chat-cbor example which is more advanced ? In the example you could also explain why someone wants to use CBOR. Dominik From aleravat at witekio.com Thu Jan 18 10:34:56 2018 From: aleravat at witekio.com (Adrien LERAVAT) Date: Thu, 18 Jan 2018 09:34:56 +0000 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: <5925207.XClqdvNNj2@walt> References: <5925207.XClqdvNNj2@walt> Message-ID: On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote: > > In that case, the QCoapReply life is managed with a > > QSharedPointer in the request. > > > > QCoapRequest does not inherit from QObject. Anyone sees a problem with > > this approach? > The API sounds interesting, but it's a departure of what we are used in QNAM. > What happened to the idea of using a setter on the manager, for making the replies self-delete if wanted? (it was mentioned on the > QtCS) That had the advantage that can be added to QNAM as well, so both can end up having a similar API. Well it can surely solve the "forgot to delete reply" case, but as a developer, if you're not aware of the change (not the one calling the setter), the new behavior change will be far from obvious. Going from "pseudo memory leak" to "dangling pointers & crashes" if they are not careful enough. So it has the advantage to be applicable to QNAM, but doesn't really feel like a user-proof solution to me. Still it can be easily applied to QCoapClient, so if there is a consensus around it, we can go that way. Adrien Leravat Software architect, Witekio http://witekio.com From annulen at yandex.ru Thu Jan 18 10:37:39 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 18 Jan 2018 12:37:39 +0300 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: References: <5925207.XClqdvNNj2@walt> Message-ID: <2532311516268259@web19j.yandex.ru> 18.01.2018, 12:35, "Adrien LERAVAT" : > On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote: >>  > In that case, the QCoapReply life is managed with a >>  > QSharedPointer in the request. >>  > >>  > QCoapRequest does not inherit from QObject. Anyone sees a problem with >>  > this approach? > >>  The API sounds interesting, but it's a departure of what we are used in QNAM. >>  What happened to the idea of using a setter on the manager, for making the replies self-delete if wanted? (it was mentioned on the > QtCS) That had the advantage that can be added to QNAM as well, so both can end up having a similar API. > > Well it can surely solve the "forgot to delete reply" case, but as a developer, if you're not aware of the change (not the one calling the setter), the new behavior change will be far from obvious. Going from "pseudo memory leak" to "dangling pointers & crashes" if they are not careful enough. On small device crashes are more favorable outcome than "pseudo" memory leaks, because the latter lead to delayed crashes and therefore are much harder to fix. > So it has the advantage to be applicable to QNAM, but doesn't really feel like a user-proof solution to me. > > Still it can be easily applied to QCoapClient, so if there is a consensus around it, we can go that way. > > Adrien Leravat > Software architect, Witekio > http://witekio.com > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From annulen at yandex.ru Thu Jan 18 10:41:36 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 18 Jan 2018 12:41:36 +0300 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: References: Message-ID: <2557501516268496@web19j.yandex.ru> 14.01.2018, 20:50, "Adrien LERAVAT" : > Hi all, > > Before feature freeze, we wanted to challenge the current API for the CoAP module. > > It is currently similar to QNAM APIs: > > \code > > QCoapClient client; > > QCoapReply *reply = client.get(QUrl("1.2.3.4:5683")); > > connect(reply, &QCoapReply::finished, this, &MyClass::onFinished); > > ... > > MyClass::onFinished(QCoapReply* reply) > > { > >     qWarning() << reply->readAll(); > >     reply->deleteLater(); > > } > > \endcode > > With the clear drawback of explicit memory management needed by users. We made > > some tests with a container/RAII object for the reply, and it seems fine, but before > > moving forward in this limited timeframe, we wanted to have your feedback. > > Sample below: > > \code > > QCoapClient client; > > QCoapRequest request = client.get(QUrl("1.2.3.4:5683")); > > connect(request.reply(), &QCoapReply::finished, this, &MyClass::onFinished); > > ... > > MyClass::onFinished(const QCoapRequest &request) > > { > >     qWarning() << request.reply()->readAll(); > > } > \endcode > > In that case, the QCoapReply life is managed with a QSharedPointer in the request. > > QCoapRequest does not inherit from QObject. Anyone sees a problem with this approach? I dislike idea of using external reference counting, making it QExplicitlySharedDataPointer would be better > > As it wasn't merged to master yet, you can access the repo from its current submission: > > https://codereview.qt-project.org/#/c/201311/ > > Thanks, > > Adrien Leravat > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From miikka.heikkinen at qt.io Thu Jan 18 10:48:59 2018 From: miikka.heikkinen at qt.io (Miikka Heikkinen) Date: Thu, 18 Jan 2018 09:48:59 +0000 Subject: [Development] Nominating Joni Poikelin for Approver status In-Reply-To: <7D30D360-2E62-4ED6-897C-12F63568DF64@qt.io> References: <7D30D360-2E62-4ED6-897C-12F63568DF64@qt.io> Message-ID: +1 from me. -Miikka From: Development [mailto:development-bounces+miikka.heikkinen=qt.io at qt-project.org] On Behalf Of Andy Shaw Sent: maanantai 15. tammikuuta 2018 12.10 To: development at qt-project.org Subject: [Development] Nominating Joni Poikelin for Approver status Hi, I would like to nominate Joni Poikelin for Approver status. He joined The Qt Company over 3 years ago and has consistently contributed to Qt across many modules, fixing a number of issues here and there. His Gerrit dashboard is here: https://codereview.qt-project.org/#/q/owner:%22Joni+Poikelin+%253Cjoni.poikelin%2540qt.io%253E%22+status:merged,n,z Disclaimer: We both work in the same team (support) inside The Qt Company. Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleravat at witekio.com Thu Jan 18 10:58:10 2018 From: aleravat at witekio.com (Adrien LERAVAT) Date: Thu, 18 Jan 2018 09:58:10 +0000 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: <2532311516268259@web19j.yandex.ru> References: <5925207.XClqdvNNj2@walt> <2532311516268259@web19j.yandex.ru> Message-ID: > From: Konstantin Tokarev [mailto:annulen at yandex.ru] > Sent: Thursday, January 18, 2018 10:42 AM > >> The API sounds interesting, but it's a departure of what we are used in QNAM. >> What happened to the idea of using a setter on the manager, for making the replies self-delete if wanted? (it was mentioned on the > QtCS) That had the advantage that can be added to QNAM as well, so both can end up having a similar API. >> >> Well it can surely solve the "forgot to delete reply" case, but as a developer, if you're not aware of the change (not the one calling the setter), the new behavior change will be far from obvious. Going from "pseudo memory leak" to "dangling pointers & crashes" if they are not careful enough. > > On small device crashes are more favorable outcome than "pseudo" memory leaks, because the latter lead to delayed crashes and therefore are much harder to fix. Well if not tested, it might just as well corrupt part of the heap with no further notice, so I'm not sure it is much better. But the question probably boils down: should we keep QNAM API or not for QtCoAP? >> So it has the advantage to be applicable to QNAM, but doesn't really feel like a user-proof solution to me. >> >> Still it can be easily applied to QCoapClient, so if there is a consensus around it, we can go that way. Adrien Leravat Software architect, Witekio http://witekio.com From annulen at yandex.ru Thu Jan 18 11:07:07 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 18 Jan 2018 13:07:07 +0300 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: References: <5925207.XClqdvNNj2@walt> <2532311516268259@web19j.yandex.ru> Message-ID: <2731841516270027@web19j.yandex.ru> 18.01.2018, 12:58, "Adrien LERAVAT" : >>  From: Konstantin Tokarev [mailto:annulen at yandex.ru] >>  Sent: Thursday, January 18, 2018 10:42 AM >> >>>   The API sounds interesting, but it's a departure of what we are used in QNAM. >>>   What happened to the idea of using a setter on the manager, for making the replies self-delete if wanted? (it was mentioned on the > QtCS) That had the advantage that can be added to QNAM as well, so both can end up having a similar API. >>> >>>  Well it can surely solve the "forgot to delete reply" case, but as a developer, if you're not aware of the change (not the one calling the setter), the new behavior change will be far from obvious. Going from "pseudo memory leak" to "dangling pointers & crashes" if they are not careful enough. >> >>  On small device crashes are more favorable outcome than "pseudo" memory leaks, because the latter lead to delayed crashes and therefore are much harder to fix. > > Well if not tested, it might just as well corrupt part of the heap with no further notice, so I'm not sure it is much better. Heap corruption can be detected with lots of existing tools, e.g. ASAN. It also won't be left unnoticed until it's too late, unlike memory leaks which may suddenly pop up when amount of data increases. Debugging out of memory conditions may be much harder. > But the question probably boils down: should we keep QNAM API or not for QtCoAP? > >>>  So it has the advantage to be applicable to QNAM, but doesn't really feel like a user-proof solution to me. >>> >>>  Still it can be easily applied to QCoapClient, so if there is a consensus around it, we can go that way. > > Adrien Leravat > Software architect, Witekio > http://witekio.com -- Regards, Konstantin From rjvbertin at gmail.com Thu Jan 18 15:12:42 2018 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 18 Jan 2018 15:12:42 +0100 Subject: [Development] QHash Message-ID: <3606740.s4rWMr7BtV@bola> Hi, It took me a while to figure out why my QHash map of a const char* to something else didn't work despite containing the expected key,value combinations. I understand that the bug was in my code rather than in QHash, because the class is not designed to work with basic data types. It could help though if a compiler error were raised in this kind of situation, would that be possible? thanks, R. From annulen at yandex.ru Thu Jan 18 15:15:57 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 18 Jan 2018 17:15:57 +0300 Subject: [Development] QHash In-Reply-To: <3606740.s4rWMr7BtV@bola> References: <3606740.s4rWMr7BtV@bola> Message-ID: <2661516284957@web2o.yandex.ru> 18.01.2018, 17:13, "René J.V. Bertin" : > Hi, > > It took me a while to figure out why my QHash map of a const char* to something else didn't work despite containing the expected key,value combinations. I understand that the bug was in my code rather than in QHash, because the class is not designed to work with basic data types. > > It could help though if a compiler error were raised in this kind of situation, would that be possible? Using pointer as key type is a valid, though may be not frequent, use case. All std containers behave the same way. > > thanks, > R. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From lars.knoll at qt.io Thu Jan 18 15:15:56 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 18 Jan 2018 14:15:56 +0000 Subject: [Development] QHash In-Reply-To: <3606740.s4rWMr7BtV@bola> References: <3606740.s4rWMr7BtV@bola> Message-ID: > On 18 Jan 2018, at 15:12, René J.V. Bertin wrote: > > Hi, > > It took me a while to figure out why my QHash map of a const char* to something else didn't work despite containing the expected key,value combinations. I understand that the bug was in my code rather than in QHash, because the class is not designed to work with basic data types. It does work with basic data types. It just did something else than you maybe expected (hashing on the value of the char * pointer, not on the string behind it). > > It could help though if a compiler error were raised in this kind of situation, would that be possible? No, because hashing on pointer values is a completely valid use case. Cheers, Lars From frederik.gladhorn at qt.io Thu Jan 18 16:34:14 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 18 Jan 2018 16:34:14 +0100 Subject: [Development] QUIP 101: Contributing to Qt Message-ID: <3341087.5HTFLzxLpr@frederik-thinkcentre-m93p> Hi all, I just pushed a QUIP that I hope captures some of our philosophy and ideas behind the Qt Project when it comes to contributing to Qt. I didn't discuss it with many people yet, so it may be controversial. I'd like to get feedback of course :) https://codereview.qt-project.org/#/c/217216/ Cheers, Frederik From thiago.macieira at intel.com Thu Jan 18 16:44:48 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 18 Jan 2018 07:44:48 -0800 Subject: [Development] API review request: CBOR Stream reader and writer In-Reply-To: References: <2363292.KCnvKgr5nM@tjmaciei-mobl1> <1599614.N3b9CUZJvf@tjmaciei-mobl1> Message-ID: <1786252.c3zrHvmrLW@tjmaciei-mobl1> On Thursday, 18 January 2018 00:51:18 PST Dominik Holland wrote: > Am 01/18/2018 um 04:22 AM schrieb Thiago Macieira: > > On Wednesday, 17 January 2018 13:25:53 PST Thiago Macieira wrote: > >> Another idea is to update the network-chat example to use CBOR instead of > >> its plaintext protocol. In this one, I could use the stream reader and > >> writer. This example is a perfect candidate to have a CoAP version in the > >> future too. > > > > I've done this then: > > https://codereview.qt-project.org/217078 > > https://codereview.qt-project.org/217079 > > Why not keep the existing example and do a network-chat-cbor example > which is more advanced ? I can do that if people think it would be better. I hadn't thought of it, so I just modified the example. > In the example you could also explain why someone wants to use CBOR. The difference in the state machine for receiving incomplete data should be enough of a reason. Plus the fact that it no longer needs to parse strings for numbers. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jan 18 16:47:11 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 18 Jan 2018 07:47:11 -0800 Subject: [Development] QHash In-Reply-To: <3606740.s4rWMr7BtV@bola> References: <3606740.s4rWMr7BtV@bola> Message-ID: <2757295.ujkroz2Tqe@tjmaciei-mobl1> On Thursday, 18 January 2018 06:12:42 PST René J.V. Bertin wrote: > It took me a while to figure out why my QHash map of a const char* to > something else didn't work despite containing the expected key,value > combinations. I understand that the bug was in my code rather than in > QHash, because the class is not designed to work with basic data types. It works with basic data types just fine. It just doesn't decode raw pointers and compare pointed contents, like you expected. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rich at kde.org Thu Jan 18 17:51:11 2018 From: rich at kde.org (Richard Moore) Date: Thu, 18 Jan 2018 16:51:11 +0000 Subject: [Development] QtCoap: QNAM-like API or not In-Reply-To: <2731841516270027@web19j.yandex.ru> References: <5925207.XClqdvNNj2@walt> <2532311516268259@web19j.yandex.ru> <2731841516270027@web19j.yandex.ru> Message-ID: On 18 January 2018 at 10:07, Konstantin Tokarev wrote: > > > Heap corruption can be detected with lots of existing tools, e.g. ASAN. It > also won't be left unnoticed until it's too late, unlike memory leaks which > may suddenly pop up when amount of data increases. > > Debugging out of memory conditions may be much harder. > ​I suggested adding detection of QNetworkReplies that weren't delete after a short time period (a few seconds perhaps) as an idea for gammaray to help with this issue. Cheers Rich. ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.savi at gaess.ch Thu Jan 18 22:42:59 2018 From: daniel.savi at gaess.ch (Daniel Savi) Date: Thu, 18 Jan 2018 22:42:59 +0100 Subject: [Development] how to include further changes while previous commit is still under review? Message-ID: Hello qt devs I'm back with another newbie question. I have committed a patch that is still under review on gerrit. Meanwhile, I've got a local and unrelated patch on the same file, that I would like to commit, too. Now, how would I include this patch into my local git repo and how would I commit it as a separate patch to the first? How could I still work on the first patch, once more comments are coming in? Would I create separate branches? Sorry for my very basic level of git-foo. From samuel.gaist at edeltech.ch Thu Jan 18 23:58:19 2018 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Thu, 18 Jan 2018 23:58:19 +0100 Subject: [Development] how to include further changes while previous commit is still under review? In-Reply-To: References: Message-ID: <27F59684-3E21-47DB-806E-E6A015D6095A@edeltech.ch> > On 18 Jan 2018, at 22:42, Daniel Savi wrote: > > Hello qt devs > > I'm back with another newbie question. I have committed a patch that is still under review on gerrit. > > Meanwhile, I've got a local and unrelated patch on the same file, that I would like to commit, too. > > Now, how would I include this patch into my local git repo and how would I commit it as a separate patch to the first? > > How could I still work on the first patch, once more comments are coming in? > > Would I create separate branches? > > Sorry for my very basic level of git-foo. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Hi, Since the patch is unrelated, use a different topic branch for that one and submit it like the other one. Depending on the impact of your change, you might want to look at https://git-scm.com/docs/git-worktree and have a separate build for it. Cheers Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From denis.shienkov at gmail.com Fri Jan 19 11:15:13 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 19 Jan 2018 13:15:13 +0300 Subject: [Development] How to use ANDROID_EXTRA_PLUGINS property in qmake projects Message-ID: <9b732b1b-2e8f-5724-1219-3c6b185c50d9@gmail.com> Hi all. I have created a custom qt-positioning plugin, which just every second provides a new fake position/coordinate. This plugin work perfectly e.g. on Windows, but it does not work on Android, as it does not loaded, because it wrongly deployed to APK file. I have read about the ANDROID_EXTRA_PLUGINS property: http://doc.qt.io/qt-5/deployment-android.html. But there are no any examples how to use this property (nor in examples, not in google). It is unclear at all how to use this property. I have tried different combinations, but it does not work at all. I have tried to specify a different output paths to my plugin (as a full paths, as a directory only and so on). I have found only one similar issue on stackoverflow: https://stackoverflow.com/questions/47061829/how-to-deploy-qt-imageformats-plugins-on-android but from there it is unclear what I need to add to the ANDROID_EXTRA_PLUGINS property (or a directory path or a full path... a path to where?). I have created a bug https://bugreports.qt.io/browse/QTBUG-65864 with an test project. Whether someone has experience of creation of a custom Qt plugins for Android? BR, Denis From denis.shienkov at gmail.com Fri Jan 19 12:29:16 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 19 Jan 2018 14:29:16 +0300 Subject: [Development] How to use ANDROID_EXTRA_PLUGINS property in qmake projects In-Reply-To: <9b732b1b-2e8f-5724-1219-3c6b185c50d9@gmail.com> References: <9b732b1b-2e8f-5724-1219-3c6b185c50d9@gmail.com> Message-ID: I have found a solution and have updated the bug, where I added a source project with correct solution: https://bugreports.qt.io/browse/QTBUG-65864 Maybe it will helps to anybody else. PS: Needs to extend a doc about using of the ANDROID_EXTRA_PLUGINS anyway... PS2: Also, the qmake copies this library twice to the android-build directory... 19.01.2018 13:15, Denis Shienkov пишет: > Hi all. > > I have created a custom qt-positioning plugin, which just > every second provides a new fake position/coordinate. > > This plugin work perfectly e.g. on Windows, but it does not > work on Android, as it does not loaded, because it wrongly > deployed to APK file. > > I have read about the ANDROID_EXTRA_PLUGINS property: > http://doc.qt.io/qt-5/deployment-android.html. But there > are no any examples how to use this property (nor in examples, > not in google). It is unclear at all how to use this property. > > I have tried different combinations, but it does not work at > all. I have tried to specify a different output paths to my > plugin (as a full paths, as a directory only and so on). > > I have found only one similar issue on stackoverflow: > https://stackoverflow.com/questions/47061829/how-to-deploy-qt-imageformats-plugins-on-android > > > but from there it is unclear what I need to add to the > ANDROID_EXTRA_PLUGINS property (or a directory path or > a full path... a path to where?). > > I have created a bug https://bugreports.qt.io/browse/QTBUG-65864 > with an test project. > > Whether someone has experience of creation of > a custom Qt plugins for Android? > > BR, > Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesus.fernandez at qt.io Fri Jan 19 16:15:52 2018 From: jesus.fernandez at qt.io (Jesus Fernandez) Date: Fri, 19 Jan 2018 15:15:52 +0000 Subject: [Development] Setters: Clarifying the ownership Message-ID: Hi all! I always found something annoying in the Qt API. The problem comes with the setters of our properties. When I want to pass an object to a property I never know if I need to take care of the object or relay on parenting system to avoid memory leaks. To know if the object is going to be reparented, I open the assistant and look for the setter to try to find the famous "takes ownership of" in the function description. Mårten Nordheim and I were talking about possible solutions to this problem. Typical things came to the discussion: - adding a macro like Q_TAKES_OWNERSHIP to the function that expands to nothing - wrapping the parameters with a template class (gsl::owner) - ... After some discussion he came with the idea of add a different "verb" to the setter, replace "set" with "give". So when we are giving the ownership of an object to instead of setSomething(&object); we will write giveSomething(&object); I really like this solution, it will improve a lot the readability of the client (and internal) code. For example: QCoreApplication::setEventDispatcher will be QCoreApplication::giveEventDispatcher. Of course at the beginning this will be a new function and the old set* functions will be kept, but marked as deprecated. -- Best regards, Jesús -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Jan 19 16:42:23 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 19 Jan 2018 18:42:23 +0300 Subject: [Development] Setters: Clarifying the ownership In-Reply-To: References: Message-ID: <589571516376543@web43g.yandex.ru> 19.01.2018, 18:16, "Jesus Fernandez" : > Hi all! > > I always found something annoying in the Qt API. The problem comes with the setters of our properties. When I want to pass an object to a property I never know if I need to take care of the object or relay on parenting system to avoid memory leaks. > To know if the object is going to be reparented, I open the assistant and look for the setter to try to find the famous "takes ownership of" in the function description. > > Mårten Nordheim and I were talking about possible solutions to this problem. Typical things came to the discussion: > - adding a macro like Q_TAKES_OWNERSHIP to the function that expands to nothing > - wrapping the parameters with a template class (gsl::owner) > - ... > > After some discussion he came with the idea of add a different "verb" to the setter, replace "set" with "give". So when we are giving the ownership of an object to instead of setSomething(&object); we will write giveSomething(&object); I really like this solution, it will improve a lot the readability of the client (and internal) code. > > For example: QCoreApplication::setEventDispatcher will be QCoreApplication::giveEventDispatcher. > > Of course at the beginning this will be a new function and the old set* functions will be kept, but marked as deprecated. FWIW, as we are talking about API changes, I pretty much like modern WebKit's conventions: 1. When function takes ownership on object, argument type is T&& or std::unique_ptr&& 2. When function is a factory and gives up ownership, it returns std::unique_ptr 3. When function needs to modify object, but doesn't take ownership, it uses T* is pointer can be nullptr, and T& otherwise The latter item contradicts Qt's tradition of avoiding references, but I found it very convenient, at least inside implementation. It allowed to get rid of many excessive null checks inside QtWebKit code and fix some missing null checks. > > -- > Best regards, > Jesús > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From Jaroslaw.Kobus at qt.io Fri Jan 19 17:09:21 2018 From: Jaroslaw.Kobus at qt.io (Jaroslaw Kobus) Date: Fri, 19 Jan 2018 16:09:21 +0000 Subject: [Development] Setters: Clarifying the ownership In-Reply-To: References: Message-ID: "give" may be confused with "get", which is usually an accessor. I may also think "Am I giving (to QCoreApplication)" or "The QCoreApplication is giving (me)". Maybe it is just a matter of the other verb? Absorb, hand over, hand on, suck in, swallow... Jarek ________________________________ From: Development on behalf of Jesus Fernandez Sent: Friday, January 19, 2018 4:15:52 PM To: development at qt-project.org Subject: [Development] Setters: Clarifying the ownership Hi all! I always found something annoying in the Qt API. The problem comes with the setters of our properties. When I want to pass an object to a property I never know if I need to take care of the object or relay on parenting system to avoid memory leaks. To know if the object is going to be reparented, I open the assistant and look for the setter to try to find the famous "takes ownership of" in the function description. Mårten Nordheim and I were talking about possible solutions to this problem. Typical things came to the discussion: - adding a macro like Q_TAKES_OWNERSHIP to the function that expands to nothing - wrapping the parameters with a template class (gsl::owner) - ... After some discussion he came with the idea of add a different "verb" to the setter, replace "set" with "give". So when we are giving the ownership of an object to instead of setSomething(&object); we will write giveSomething(&object); I really like this solution, it will improve a lot the readability of the client (and internal) code. For example: QCoreApplication::setEventDispatcher will be QCoreApplication::giveEventDispatcher. Of course at the beginning this will be a new function and the old set* functions will be kept, but marked as deprecated. -- Best regards, Jesús -------------- next part -------------- An HTML attachment was scrubbed... URL: From philwave at gmail.com Fri Jan 19 17:26:21 2018 From: philwave at gmail.com (Philippe) Date: Fri, 19 Jan 2018 17:26:21 +0100 Subject: [Development] Setters: Clarifying the ownership In-Reply-To: References: Message-ID: <20180119172620.51FA.6F0322A@gmail.com> +20 years ago, the (good) Taligent crossplatform project, in its guideline, proposed: adopt() aka "take ownership" orphan() aka "release ownership" Philippe On Fri, 19 Jan 2018 16:09:21 +0000 Jaroslaw Kobus wrote: > "give" may be confused with "get", which is usually an accessor. I may also think "Am I giving (to QCoreApplication)" or "The QCoreApplication is giving (me)". Maybe it is just a matter of the other verb? Absorb, hand over, hand on, suck in, swallow... > > > Jarek > > > > ------------------------------------------------------------ > From: Development on behalf of Jesus Fernandez > Sent: Friday, January 19, 2018 4:15:52 PM > To: development at qt-project.org > Subject: [Development] Setters: Clarifying the ownership > > > Hi all! > > I always found something annoying in the Qt API. The problem comes with the setters of our properties. When I want to pass an object to a property I never know if I need to take care of the object or relay on parenting system to avoid memory leaks. > To know if the object is going to be reparented, I open the assistant and look for the setter to try to find the famous "takes ownership of" in the function description. > > Mårten Nordheim and I were talking about possible solutions to this problem. Typical things came to the discussion: > - adding a macro like Q_TAKES_OWNERSHIP to the function that expands to nothing > - wrapping the parameters with a template class (gsl::owner) > - ... > > After some discussion he came with the idea of add a different "verb" to the setter, replace "set" with "give". So when we are giving the ownership of an object to instead of setSomething(&object); we will write giveSomething(&object); I really like this solution, it will improve a lot the readability of the client (and internal) code. > > For example: QCoreApplication::setEventDispatcher will be QCoreApplication::giveEventDispatcher. > Of course at the beginning this will be a new function and the old set* functions will be kept, but marked as deprecated. > > > -- > Best regards, > Jesús > From thiago.macieira at intel.com Fri Jan 19 17:57:21 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 19 Jan 2018 08:57:21 -0800 Subject: [Development] Setters: Clarifying the ownership In-Reply-To: <20180119172620.51FA.6F0322A@gmail.com> References: <20180119172620.51FA.6F0322A@gmail.com> Message-ID: <3425505.BBm1Ucay7Y@tjmaciei-mobl1> On sexta-feira, 19 de janeiro de 2018 08:26:21 PST Philippe wrote: > +20 years ago, the (good) Taligent crossplatform project, in its guideline, > proposed: > > adopt() aka "take ownership" > > orphan() aka "release ownership" Given that we already have "take" methods that release ownership in the Qt containers, that won't work. See QList / QVector::takeAt. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From adam.treat at qt.io Fri Jan 19 18:06:37 2018 From: adam.treat at qt.io (Adam Treat) Date: Fri, 19 Jan 2018 12:06:37 -0500 Subject: [Development] Setters: Clarifying the ownership In-Reply-To: <3425505.BBm1Ucay7Y@tjmaciei-mobl1> References: <20180119172620.51FA.6F0322A@gmail.com> <3425505.BBm1Ucay7Y@tjmaciei-mobl1> Message-ID: <2f332cb0-7093-22f7-b5f0-635e5ec9fa00@qt.io> How about "transfer" On 01/19/2018 11:57 AM, Thiago Macieira wrote: > On sexta-feira, 19 de janeiro de 2018 08:26:21 PST Philippe wrote: >> +20 years ago, the (good) Taligent crossplatform project, in its guideline, >> proposed: >> >> adopt() aka "take ownership" >> >> orphan() aka "release ownership" > Given that we already have "take" methods that release ownership in the Qt > containers, that won't work. See QList / QVector::takeAt. > From annulen at yandex.ru Fri Jan 19 18:09:27 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 19 Jan 2018 20:09:27 +0300 Subject: [Development] Setters: Clarifying the ownership In-Reply-To: <2f332cb0-7093-22f7-b5f0-635e5ec9fa00@qt.io> References: <20180119172620.51FA.6F0322A@gmail.com> <3425505.BBm1Ucay7Y@tjmaciei-mobl1> <2f332cb0-7093-22f7-b5f0-635e5ec9fa00@qt.io> Message-ID: <791611516381767@web18o.yandex.ru> 19.01.2018, 20:07, "Adam Treat" : > How about "transfer" Why not just use move semantics of language instead of inventing new terms? > > On 01/19/2018 11:57 AM, Thiago Macieira wrote: >>  On sexta-feira, 19 de janeiro de 2018 08:26:21 PST Philippe wrote: >>>  +20 years ago, the (good) Taligent crossplatform project, in its guideline, >>>  proposed: >>> >>>  adopt() aka "take ownership" >>> >>>  orphan() aka "release ownership" >>  Given that we already have "take" methods that release ownership in the Qt >>  containers, that won't work. See QList / QVector::takeAt. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From edward.welbourne at qt.io Fri Jan 19 18:26:10 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 19 Jan 2018 17:26:10 +0000 Subject: [Development] Setters: Clarifying the ownership In-Reply-To: References: , Message-ID: Jaroslaw Kobus (19 January 2018 17:09) > "give" may be confused with "get", which is usually an accessor. I may > also think "Am I giving (to QCoreApplication)" or "The > QCoreApplication is giving (me)". Maybe it is just a matter of the > other verb? Absorb, hand over, hand on, suck in, swallow... However, we have plenty of take functions, where the caller takes ownership from the object on which the method is called; so it makes sense that a give function would be the caller giving ownership to the object on wich the method is called. Thus we'd keep child.setParent(newParent), since the child doesn't take ownership of the parent; but QMainWindow's setCentralWidget() would become giveCentralWidget(), matching its takeCentralWidget(). This would save the search for its doc, to find that it does indeed take ownership. The signature is, in any case, always sufficient to make clear that a give()r isn't a get()ter. Eddy. From annulen at yandex.ru Fri Jan 19 18:40:07 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 19 Jan 2018 20:40:07 +0300 Subject: [Development] how to include further changes while previous commit is still under review? In-Reply-To: <27F59684-3E21-47DB-806E-E6A015D6095A@edeltech.ch> References: <27F59684-3E21-47DB-806E-E6A015D6095A@edeltech.ch> Message-ID: <3094321516383607@web41g.yandex.ru> 19.01.2018, 01:58, "Samuel Gaist" : >>  On 18 Jan 2018, at 22:42, Daniel Savi wrote: >> >>  Hello qt devs >> >>  I'm back with another newbie question. I have committed a patch that is still under review on gerrit. >> >>  Meanwhile, I've got a local and unrelated patch on the same file, that I would like to commit, too. >> >>  Now, how would I include this patch into my local git repo and how would I commit it as a separate patch to the first? >> >>  How could I still work on the first patch, once more comments are coming in? >> >>  Would I create separate branches? >> >>  Sorry for my very basic level of git-foo. >> >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > Hi, > > Since the patch is unrelated, use a different topic branch for that one and submit it like the other one. > > Depending on the impact of your change, you might want to look at https://git-scm.com/docs/git-worktree and have a separate build for it. I think it's OK to create it in the same branch with previous one, especially in this case when patches touch same file and there is a non-zero probability of conflict because of order change. While patch #2 will have #1 shown in Gerrit as a "dependency", they still can be integrated separately from each other (if #2 does actually apply to the branch without #1). > > Cheers > > Samuel > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Fri Jan 19 19:32:49 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 19 Jan 2018 10:32:49 -0800 Subject: [Development] Setters: Clarifying the ownership In-Reply-To: References: Message-ID: <3843684.v7fED68053@tjmaciei-mobl1> On Friday, 19 January 2018 09:26:10 PST Edward Welbourne wrote: > Jaroslaw Kobus (19 January 2018 17:09) > > > "give" may be confused with "get", which is usually an accessor. I may > > also think "Am I giving (to QCoreApplication)" or "The > > QCoreApplication is giving (me)". Maybe it is just a matter of the > > other verb? Absorb, hand over, hand on, suck in, swallow... > > However, we have plenty of take functions, where the caller takes > ownership from the object on which the method is called; so it makes > sense that a give function would be the caller giving ownership to the > object on wich the method is called. > > Thus we'd keep child.setParent(newParent), since the child doesn't take > ownership of the parent; but QMainWindow's setCentralWidget() would > become giveCentralWidget(), matching its takeCentralWidget(). This > would save the search for its doc, to find that it does indeed take > ownership. > > The signature is, in any case, always sufficient to make clear that a > give()r isn't a get()ter. Let's stop the discussion about method *naming* right here. We're not going to change hundreds of getters and setters now or even in Qt 6. Let's instead find a solution that either uses macros or uses simple binary- compatible pointer wrappers like GST. And be careful with template functions. Changing from T to Something may change what gets deduced. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From eric.lemanissier at gmail.com Sat Jan 20 09:17:43 2018 From: eric.lemanissier at gmail.com (Eric Lemanisser) Date: Sat, 20 Jan 2018 08:17:43 +0000 Subject: [Development] Setters: Clarifying the ownership In-Reply-To: <3843684.v7fED68053@tjmaciei-mobl1> References: <3843684.v7fED68053@tjmaciei-mobl1> Message-ID: Please use an already existing solution to this problem : https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Ri-raw Errors will be caught by the compiler in case of std::unique_ptr, and by static analysers (like clang-tidy) for gsl::owner, without run-time cost. There was already an attempt to use gsl::owner https://codereview.qt-project.org/#/c/178107/ but it did not go forward, because of lack of time ? Le ven. 19 janv. 2018 à 19:33, Thiago Macieira a écrit : > On Friday, 19 January 2018 09:26:10 PST Edward Welbourne wrote: > > Jaroslaw Kobus (19 January 2018 17:09) > > > > > "give" may be confused with "get", which is usually an accessor. I may > > > also think "Am I giving (to QCoreApplication)" or "The > > > QCoreApplication is giving (me)". Maybe it is just a matter of the > > > other verb? Absorb, hand over, hand on, suck in, swallow... > > > > However, we have plenty of take functions, where the caller takes > > ownership from the object on which the method is called; so it makes > > sense that a give function would be the caller giving ownership to the > > object on wich the method is called. > > > > Thus we'd keep child.setParent(newParent), since the child doesn't take > > ownership of the parent; but QMainWindow's setCentralWidget() would > > become giveCentralWidget(), matching its takeCentralWidget(). This > > would save the search for its doc, to find that it does indeed take > > ownership. > > > > The signature is, in any case, always sufficient to make clear that a > > give()r isn't a get()ter. > > Let's stop the discussion about method *naming* right here. We're not > going to > change hundreds of getters and setters now or even in Qt 6. > > Let's instead find a solution that either uses macros or uses simple > binary- > compatible pointer wrappers like GST. > > And be careful with template functions. Changing from T to Something may > change what gets deduced. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.savi at gaess.ch Sat Jan 20 23:24:06 2018 From: daniel.savi at gaess.ch (Daniel Savi) Date: Sat, 20 Jan 2018 23:24:06 +0100 Subject: [Development] how to include further changes while previous commit is still under review? In-Reply-To: <3094321516383607@web41g.yandex.ru> References: <27F59684-3E21-47DB-806E-E6A015D6095A@edeltech.ch> <3094321516383607@web41g.yandex.ru> Message-ID: On 19.01.2018 18:40, Konstantin Tokarev wrote: > > 19.01.2018, 01:58, "Samuel Gaist" : >>>  On 18 Jan 2018, at 22:42, Daniel Savi wrote: >>> >>>  Hello qt devs >>> >>>  I'm back with another newbie question. I have committed a patch that is still under review on gerrit. >>> >>>  Meanwhile, I've got a local and unrelated patch on the same file, that I would like to commit, too. >>> >>>  Now, how would I include this patch into my local git repo and how would I commit it as a separate patch to the first? >>> >>>  How could I still work on the first patch, once more comments are coming in? >>> >>>  Would I create separate branches? >>> >>>  Sorry for my very basic level of git-foo. >>> >>>  _______________________________________________ >>>  Development mailing list >>>  Development at qt-project.org >>>  http://lists.qt-project.org/mailman/listinfo/development >> Hi, >> >> Since the patch is unrelated, use a different topic branch for that one and submit it like the other one. >> >> Depending on the impact of your change, you might want to look at https://git-scm.com/docs/git-worktree and have a separate build for it. I will read that, thank you for the link. > I think it's OK to create it in the same branch with previous one, especially in this case when patches touch same file > and there is a non-zero probability of conflict because of order change. > > While patch #2 will have #1 shown in Gerrit as a "dependency", they still can be integrated separately from each other (if #2 does actually apply to the branch without #1). Just one question. Patch #1 is still under review and there will probably be further changes in the future. If I have patch #2 on the same branch and commit changes to patch #1 again later with "git commit -a --amend", wouldn't patch #2 be included in patch #1, too? >> Cheers >> >> Samuel >> , >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Sat Jan 20 23:28:13 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 21 Jan 2018 01:28:13 +0300 Subject: [Development] how to include further changes while previous commit is still under review? In-Reply-To: References: <27F59684-3E21-47DB-806E-E6A015D6095A@edeltech.ch> <3094321516383607@web41g.yandex.ru> Message-ID: <2044701516487293@web40g.yandex.ru> 21.01.2018, 01:25, "Daniel Savi" : > On 19.01.2018 18:40, Konstantin Tokarev wrote: >>  19.01.2018, 01:58, "Samuel Gaist" : >>>>    On 18 Jan 2018, at 22:42, Daniel Savi wrote: >>>> >>>>    Hello qt devs >>>> >>>>    I'm back with another newbie question. I have committed a patch that is still under review on gerrit. >>>> >>>>    Meanwhile, I've got a local and unrelated patch on the same file, that I would like to commit, too. >>>> >>>>    Now, how would I include this patch into my local git repo and how would I commit it as a separate patch to the first? >>>> >>>>    How could I still work on the first patch, once more comments are coming in? >>>> >>>>    Would I create separate branches? >>>> >>>>    Sorry for my very basic level of git-foo. >>>> >>>>    _______________________________________________ >>>>    Development mailing list >>>>    Development at qt-project.org >>>>    http://lists.qt-project.org/mailman/listinfo/development >>>  Hi, >>> >>>  Since the patch is unrelated, use a different topic branch for that one and submit it like the other one. >>> >>>  Depending on the impact of your change, you might want to look at https://git-scm.com/docs/git-worktree and have a separate build for it. > > I will read that, thank you for the link. >>  I think it's OK to create it in the same branch with previous one, especially in this case when patches touch same file >>  and there is a non-zero probability of conflict because of order change. >> >>  While patch #2 will have #1 shown in Gerrit as a "dependency", they still can be integrated separately from each other (if #2 does actually apply to the branch without #1). > > Just one question. Patch #1 is still under review and there will > probably be further changes in the future. If I have patch #2 on the > same branch and commit changes to patch #1 again later with "git commit > -a --amend", wouldn't patch #2 be included in patch #1, too? git commit --amend edits topmost patch, i.e. #2, instead of #1 So if you make changes for #1 you need to create new commit #3, and squash #3 and #1 with git rebase -i >>>  Cheers >>> >>>  Samuel >>>  , >>> >>>  _______________________________________________ >>>  Development mailing list >>>  Development at qt-project.org >>>  http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From daniel.savi at gaess.ch Mon Jan 22 07:33:17 2018 From: daniel.savi at gaess.ch (Daniel Savi) Date: Mon, 22 Jan 2018 07:33:17 +0100 Subject: [Development] how to include further changes while previous commit is still under review? In-Reply-To: <2044701516487293@web40g.yandex.ru> References: <27F59684-3E21-47DB-806E-E6A015D6095A@edeltech.ch> <3094321516383607@web41g.yandex.ru> <2044701516487293@web40g.yandex.ru> Message-ID: After reading some of the excellent documentation on git-scm.com, I'm planning to create two branches, one for patch 1 and one for patch 2. So, I would do "git branch fix1", "git checkout fix1", add some changes from review, "git commit --amend", then "git checkout master", "git branch fix2", git checkout fix2", add fix 2 and commit the second patch. I'm writing all commands by heart, may have some mistakes there. Would that work out, or am I running into troubles somewhere? Am 20. Januar 2018 23:28:13 MEZ schrieb Konstantin Tokarev : > > >21.01.2018, 01:25, "Daniel Savi" : >> On 19.01.2018 18:40, Konstantin Tokarev wrote: >>>  19.01.2018, 01:58, "Samuel Gaist" : >>>>>    On 18 Jan 2018, at 22:42, Daniel Savi >wrote: >>>>> >>>>>    Hello qt devs >>>>> >>>>>    I'm back with another newbie question. I have committed a patch >that is still under review on gerrit. >>>>> >>>>>    Meanwhile, I've got a local and unrelated patch on the same >file, that I would like to commit, too. >>>>> >>>>>    Now, how would I include this patch into my local git repo and >how would I commit it as a separate patch to the first? >>>>> >>>>>    How could I still work on the first patch, once more comments >are coming in? >>>>> >>>>>    Would I create separate branches? >>>>> >>>>>    Sorry for my very basic level of git-foo. >>>>> >>>>>    _______________________________________________ >>>>>    Development mailing list >>>>>    Development at qt-project.org >>>>>    http://lists.qt-project.org/mailman/listinfo/development >>>>  Hi, >>>> >>>>  Since the patch is unrelated, use a different topic branch for >that one and submit it like the other one. >>>> >>>>  Depending on the impact of your change, you might want to look at >https://git-scm.com/docs/git-worktree and have a separate build for it. >> >> I will read that, thank you for the link. >>>  I think it's OK to create it in the same branch with previous one, >especially in this case when patches touch same file >>>  and there is a non-zero probability of conflict because of order >change. >>> >>>  While patch #2 will have #1 shown in Gerrit as a "dependency", they >still can be integrated separately from each other (if #2 does actually >apply to the branch without #1). >> >> Just one question. Patch #1 is still under review and there will >> probably be further changes in the future. If I have patch #2 on the >> same branch and commit changes to patch #1 again later with "git >commit >> -a --amend", wouldn't patch #2 be included in patch #1, too? > >git commit --amend edits topmost patch, i.e. #2, instead of #1 > >So if you make changes for #1 you need to create new commit #3, and >squash >#3 and #1 with git rebase -i > >>>>  Cheers >>>> >>>>  Samuel >>>>  , >>>> >>>>  _______________________________________________ >>>>  Development mailing list >>>>  Development at qt-project.org >>>>  http://lists.qt-project.org/mailman/listinfo/development > >-- >Regards, >Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Mon Jan 22 10:10:59 2018 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Mon, 22 Jan 2018 10:10:59 +0100 Subject: [Development] QHash In-Reply-To: <3606740.s4rWMr7BtV@bola> References: <3606740.s4rWMr7BtV@bola> Message-ID: <5a6e63df-1a7d-8d32-7706-740356de3304@familiesomers.nl> Hi, As already pointed out by the other responders, this cannot be an error. However, perhaps it could be a Clazy check? Because I doubt QHash does what the writer intented in the general case. André Op 18/01/2018 om 15:12 schreef René J.V. Bertin: > Hi, > > It took me a while to figure out why my QHash map of a const char* to something else didn't work despite containing the expected key,value combinations. I understand that the bug was in my code rather than in QHash, because the class is not designed to work with basic data types. > > It could help though if a compiler error were raised in this kind of situation, would that be possible? > > thanks, > R. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Mon Jan 22 10:37:40 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 Jan 2018 01:37:40 -0800 Subject: [Development] API review request: CBOR Stream reader and writer In-Reply-To: <2363292.KCnvKgr5nM@tjmaciei-mobl1> References: <2363292.KCnvKgr5nM@tjmaciei-mobl1> Message-ID: <2775239.o9DK0cSrxL@tjmaciei-mobl1> On quarta-feira, 17 de janeiro de 2018 13:25:53 PST Thiago Macieira wrote: > My current idea is a command-line tool that converts between serialisation > formats: > * CBOR > * CBOR diagnostic notation (output only, since I won't write the parser) > * JSON > * XML > * Qt binary JSON > * Plain QDataStream (output only, since it's not self-describing) > * QDataStream-serialised QVariant (is self-describing) > > Though, because of the conversions, this example is ideal for QCborValue, > not the stream reader and writer. Done: https://codereview.qt-project.org/217410 I'd really appreciate if someone reviewed my code that parses XML. I've also used this example application to benchmark the various aspects of the encoder. It's helped me find a couple of bottlenecks in the implementation, which led to a redesign of the string parsing in QCborStreamReader. The current numbers, for parsing an array with 5000 entries of a map, the contents of which were obtained by: qtplugininfo --full-json /usr/lib64/qt5/plugins/akregator_config_advanced.so Binary JSON validating: 97,003559 task-clock:u (msec) 237.092.857 cycles 437.005.872 instructions [15.2% was spent in QIODevice::readAll, 59.1% in fromBinaryData] JSON parsing: 273,359723 task-clock:u (msec) 793.297.513 cycles 2.698.607.303 instructions [4.7% in readAll(), 78.2% in fromJson] CBOR parsing: 341,311535 task-clock 885.053.081 cycles 2.548.803.851 instructions The string parser is still showing up at 70.5% of the full execution time, of which 33.4% are in QCborStreamReader and 20.4% calling isValidUtf8(). The program spends 25,0% inside QIODevice, inside the string decoder. Unlike the JSON parser, we don't operate on a pre-read byte array, but directly on the QIODevice, checking for size. The JSON parser spends 56.2% of the full execution time parsing strings. As for the encoders, the test is done by reading from Binary JSON, converting to QVariant, then back from QVariant and then saving. Binary JSON (baseline): 724,619527 task-clock 1.792.421.866 cycles 2.983.986.222 instructions Time spent in toBinaryData: 1.24% JSON: 1150,128441 task-clock:u (msec) 3.179.240.094 cycles 6.673.262.299 instructions Time spent in the encoder: 34.5%, so ~403 ms CBOR: 930,697635 task-clock:u (msec) 2.391.326.016 cycles 4.910.714.973 instructions Time spent in the encoder: 21.2%, so 176 ms File sizes: Binary JSON: 55,540,020 bytes (546 MB/s on read, 5900 MB/s write) JSON: 57,580,003 bytes (201 MB/s read, 136 MB/s write) CBOR: 41,200,002 bytes (115 MB/s read, 223 MB/s write) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Mon Jan 22 11:31:35 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 22 Jan 2018 13:31:35 +0300 Subject: [Development] how to include further changes while previous commit is still under review? In-Reply-To: References: <27F59684-3E21-47DB-806E-E6A015D6095A@edeltech.ch> <3094321516383607@web41g.yandex.ru> <2044701516487293@web40g.yandex.ru> Message-ID: <614061516617095@web53j.yandex.ru> 22.01.2018, 09:34, "Daniel Savi" : > After reading some of the excellent documentation on git-scm.com, I'm planning to create two branches, one for patch 1 and one for patch 2. So, I would do "git branch fix1", "git checkout fix1", add some changes from review, "git commit --amend", then "git checkout master", "git branch fix2", git checkout fix2", add fix 2 and commit the second patch. I'm writing all commands by heart, may have some mistakes there. > Would that work out, or am I running into troubles somewhere? 1. "git branch fix1", "git checkout fix1" is usually done in one step: git checkout -b fix1 2. Yes, this is going to work, and moreover, it's probably the best approach from theoretic point of view, also known as "feature branches". What I've suggested is a pragmatic shortcut, to avoid switching branches and therefore save a bit of time by avoid excessive file rewrites and following recompilation. > Am 20. Januar 2018 23:28:13 MEZ schrieb Konstantin Tokarev : >> 21.01.2018, 01:25, "Daniel Savi" : On 19.01.2018 18:40, Konstantin Tokarev wrote:  19.01.2018, 01:58, "Samuel Gaist" :    On 18 Jan 2018, at 22:42, Daniel Savi wrote:    Hello qt devs    I'm back with another newbie question. I have committed a patch that is still under review on gerrit.    Meanwhile, I've got a local and unrelated patch on the same file, that I would like to commit, too.    Now, how would I include this patch into my local git repo and how would I commit it as a separate patch to the first?    How could I still work on the first patch, once more comments are coming in?    Would I create separate branches?    Sorry for my very basic level of git-foo. >>>>>> ---------------------------------------- >>>>>> >>>>>>    Development mailing list >>>>>>    Development at qt-project.org >>>>>>    http://lists.qt-project.org/mailman/listinfo/development >>>>>  Hi, >>>>> >>>>>  Since the patch is unrelated, use a different topic branch for that one and submit it like the other one. >>>>> >>>>>  Depending on the impact of your change, you might want to look at https://git-scm.com/docs/git-worktree and have a separate build for it. >>> >>> I will read that, thank you for the link. >>>>  I think it's OK to create it in the same branch with previous one, especially in this case when patches touch same file >>>>  and there is a non-zero probability of conflict because of order change. >>>> >>>>  While patch #2 will have #1 shown in Gerrit as a "dependency", they still can be integrated separately from each other (if #2 does actually apply to the branch without #1). >>> >>> Just one question. Patch #1 is still under review and there will >>> probably be further changes in the future. If I have patch #2 on the >>> same branch and commit changes to patch #1 again later with "git commit >>> -a --amend", wouldn't patch #2 be included in patch #1, too? >> >> git commit --amend edits topmost patch, i.e. #2, instead of #1 >> >> So if you make changes for #1 you need to create new commit #3, and squash >> #3 and #1 with git rebase -i >> >>>>>  Cheers >>>>> >>>>>  Samuel >>>>>  , >>>>> >>>>> ---------------------------------------- >>>>> >>>>>  Development mailing list >>>>>  Development at qt-project.org >>>>>  http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From Marco.Bubke at qt.io Mon Jan 22 11:39:05 2018 From: Marco.Bubke at qt.io (Marco Bubke) Date: Mon, 22 Jan 2018 10:39:05 +0000 Subject: [Development] Setters: Clarifying the ownership In-Reply-To: References: <3843684.v7fED68053@tjmaciei-mobl1>, Message-ID: Using a standard from the Cpp Core Guidelines will have the advantage of better tooling support. And please don't use the preprocessor, it will down slow the refactoring or makes it impossible. ________________________________ From: Development on behalf of Eric Lemanisser Sent: Saturday, January 20, 2018 9:17:43 AM To: Thiago Macieira Cc: development at qt-project.org Subject: Re: [Development] Setters: Clarifying the ownership Please use an already existing solution to this problem : https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Ri-raw Errors will be caught by the compiler in case of std::unique_ptr, and by static analysers (like clang-tidy) for gsl::owner, without run-time cost. There was already an attempt to use gsl::owner https://codereview.qt-project.org/#/c/178107/ but it did not go forward, because of lack of time ? Le ven. 19 janv. 2018 à 19:33, Thiago Macieira > a écrit : On Friday, 19 January 2018 09:26:10 PST Edward Welbourne wrote: > Jaroslaw Kobus (19 January 2018 17:09) > > > "give" may be confused with "get", which is usually an accessor. I may > > also think "Am I giving (to QCoreApplication)" or "The > > QCoreApplication is giving (me)". Maybe it is just a matter of the > > other verb? Absorb, hand over, hand on, suck in, swallow... > > However, we have plenty of take functions, where the caller takes > ownership from the object on which the method is called; so it makes > sense that a give function would be the caller giving ownership to the > object on wich the method is called. > > Thus we'd keep child.setParent(newParent), since the child doesn't take > ownership of the parent; but QMainWindow's setCentralWidget() would > become giveCentralWidget(), matching its takeCentralWidget(). This > would save the search for its doc, to find that it does indeed take > ownership. > > The signature is, in any case, always sufficient to make clear that a > give()r isn't a get()ter. Let's stop the discussion about method *naming* right here. We're not going to change hundreds of getters and setters now or even in Qt 6. Let's instead find a solution that either uses macros or uses simple binary- compatible pointer wrappers like GST. And be careful with template functions. Changing from T to Something may change what gets deduced. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Smith at qt.io Mon Jan 22 12:34:53 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 22 Jan 2018 11:34:53 +0000 Subject: [Development] how to include further changes while previous commit is still under review? In-Reply-To: <614061516617095@web53j.yandex.ru> References: <27F59684-3E21-47DB-806E-E6A015D6095A@edeltech.ch> <3094321516383607@web41g.yandex.ru> <2044701516487293@web40g.yandex.ru> , <614061516617095@web53j.yandex.ru> Message-ID: When updating the documentation, I often do 2 or more different commits and pushes to a single branch. Then I wait for them to get approved. Often, a reviewer will require changes to the first pushed commit after I have pushed the second commit. Then I do: git rebase -i HEAD~2 ...and I reorder the "pick" lines. This makes the first commit accessible with: git commit --amend ...so I make the changes, use git add to make them visible to git commit --amend martin ________________________________________ From: Development on behalf of Konstantin Tokarev Sent: Monday, January 22, 2018 11:31:35 AM To: Daniel Savi; Samuel Gaist Cc: development at qt-project.org Subject: Re: [Development] how to include further changes while previous commit is still under review? 22.01.2018, 09:34, "Daniel Savi" : > After reading some of the excellent documentation on git-scm.com, I'm planning to create two branches, one for patch 1 and one for patch 2. So, I would do "git branch fix1", "git checkout fix1", add some changes from review, "git commit --amend", then "git checkout master", "git branch fix2", git checkout fix2", add fix 2 and commit the second patch. I'm writing all commands by heart, may have some mistakes there. > Would that work out, or am I running into troubles somewhere? 1. "git branch fix1", "git checkout fix1" is usually done in one step: git checkout -b fix1 2. Yes, this is going to work, and moreover, it's probably the best approach from theoretic point of view, also known as "feature branches". What I've suggested is a pragmatic shortcut, to avoid switching branches and therefore save a bit of time by avoid excessive file rewrites and following recompilation. > Am 20. Januar 2018 23:28:13 MEZ schrieb Konstantin Tokarev : >> 21.01.2018, 01:25, "Daniel Savi" : On 19.01.2018 18:40, Konstantin Tokarev wrote: 19.01.2018, 01:58, "Samuel Gaist" : On 18 Jan 2018, at 22:42, Daniel Savi wrote: Hello qt devs I'm back with another newbie question. I have committed a patch that is still under review on gerrit. Meanwhile, I've got a local and unrelated patch on the same file, that I would like to commit, too. Now, how would I include this patch into my local git repo and how would I commit it as a separate patch to the first? How could I still work on the first patch, once more comments are coming in? Would I create separate branches? Sorry for my very basic level of git-foo. >>>>>> ---------------------------------------- >>>>>> >>>>>> Development mailing list >>>>>> Development at qt-project.org >>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>> Hi, >>>>> >>>>> Since the patch is unrelated, use a different topic branch for that one and submit it like the other one. >>>>> >>>>> Depending on the impact of your change, you might want to look at https://git-scm.com/docs/git-worktree and have a separate build for it. >>> >>> I will read that, thank you for the link. >>>> I think it's OK to create it in the same branch with previous one, especially in this case when patches touch same file >>>> and there is a non-zero probability of conflict because of order change. >>>> >>>> While patch #2 will have #1 shown in Gerrit as a "dependency", they still can be integrated separately from each other (if #2 does actually apply to the branch without #1). >>> >>> Just one question. Patch #1 is still under review and there will >>> probably be further changes in the future. If I have patch #2 on the >>> same branch and commit changes to patch #1 again later with "git commit >>> -a --amend", wouldn't patch #2 be included in patch #1, too? >> >> git commit --amend edits topmost patch, i.e. #2, instead of #1 >> >> So if you make changes for #1 you need to create new commit #3, and squash >> #3 and #1 with git rebase -i >> >>>>> Cheers >>>>> >>>>> Samuel >>>>> , >>>>> >>>>> ---------------------------------------- >>>>> >>>>> Development mailing list >>>>> Development at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Mon Jan 22 12:36:38 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 22 Jan 2018 14:36:38 +0300 Subject: [Development] how to include further changes while previous commit is still under review? In-Reply-To: References: <27F59684-3E21-47DB-806E-E6A015D6095A@edeltech.ch> <3094321516383607@web41g.yandex.ru> <2044701516487293@web40g.yandex.ru> , <614061516617095@web53j.yandex.ru> Message-ID: <120031516620998@web5o.yandex.ru> An HTML attachment was scrubbed... URL: From Martin.Smith at qt.io Mon Jan 22 12:47:10 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 22 Jan 2018 11:47:10 +0000 Subject: [Development] how to include further changes while previous commit is still under review? In-Reply-To: <120031516620998@web5o.yandex.ru> References: <27F59684-3E21-47DB-806E-E6A015D6095A@edeltech.ch> <3094321516383607@web41g.yandex.ru> <2044701516487293@web40g.yandex.ru> , <614061516617095@web53j.yandex.ru> , <120031516620998@web5o.yandex.ru> Message-ID: >You are doing it wrong. In rebase -i menu don't reorder anything, instead >mark commits for edit But then you have to do the editing with the rebase paused and then continue the rebase. I feel less anxiety reordering the picks and completing the rebase before beginning the editing. martin ________________________________________ From: Konstantin Tokarev Sent: Monday, January 22, 2018 12:36:38 PM To: Martin Smith; Daniel Savi; Samuel Gaist Cc: development at qt-project.org Subject: Re: [Development] how to include further changes while previous commit is still under review? 22.01.2018, 14:34, "Martin Smith" : > When updating the documentation, I often do 2 or more different commits and pushes to a single branch. Then I wait for them to get approved. Often, a reviewer will require changes to the first pushed commit after I have pushed the second commit. Then I do: > > git rebase -i HEAD~2 > > ...and I reorder the "pick" lines. This makes the first commit accessible with: > > git commit --amend > > ...so I make the changes, use git add to make them visible to git commit --amend You are doing it wrong. In rebase -i menu don't reorder anything, instead mark commits for edit > > martin > > ________________________________________ > From: Development on behalf of Konstantin Tokarev > Sent: Monday, January 22, 2018 11:31:35 AM > To: Daniel Savi; Samuel Gaist > Cc: development at qt-project.org > Subject: Re: [Development] how to include further changes while previous commit is still under review? > > 22.01.2018, 09:34, "Daniel Savi" : >> After reading some of the excellent documentation on git-scm.com, I'm planning to create two branches, one for patch 1 and one for patch 2. So, I would do "git branch fix1", "git checkout fix1", add some changes from review, "git commit --amend", then "git checkout master", "git branch fix2", git checkout fix2", add fix 2 and commit the second patch. I'm writing all commands by heart, may have some mistakes there. >> Would that work out, or am I running into troubles somewhere? > > 1. "git branch fix1", "git checkout fix1" is usually done in one step: git checkout -b fix1 > 2. Yes, this is going to work, and moreover, it's probably the best approach from theoretic point of view, also known as "feature branches". What I've suggested is a pragmatic shortcut, to avoid switching branches and therefore save a bit of time by avoid excessive file rewrites and following recompilation. > >> Am 20. Januar 2018 23:28:13 MEZ schrieb Konstantin Tokarev : >>> 21.01.2018, 01:25, "Daniel Savi" : On 19.01.2018 18:40, Konstantin Tokarev wrote: 19.01.2018, 01:58, "Samuel Gaist" : On 18 Jan 2018, at 22:42, Daniel Savi wrote: Hello qt devs I'm back with another newbie question. I have committed a patch that is still under review on gerrit. Meanwhile, I've got a local and unrelated patch on the same file, that I would like to commit, too. Now, how would I include this patch into my local git repo and how would I commit it as a separate patch to the first? How could I still work on the first patch, once more comments are coming in? Would I create separate branches? Sorry for my very basic level of git-foo. >>>>>>> ---------------------------------------- >>>>>>> >>>>>>> Development mailing list >>>>>>> Development at qt-project.org >>>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>>> Hi, >>>>>> >>>>>> Since the patch is unrelated, use a different topic branch for that one and submit it like the other one. >>>>>> >>>>>> Depending on the impact of your change, you might want to look at https://git-scm.com/docs/git-worktree and have a separate build for it. >>>> >>>> I will read that, thank you for the link. >>>>> I think it's OK to create it in the same branch with previous one, especially in this case when patches touch same file >>>>> and there is a non-zero probability of conflict because of order change. >>>>> >>>>> While patch #2 will have #1 shown in Gerrit as a "dependency", they still can be integrated separately from each other (if #2 does actually apply to the branch without #1). >>>> >>>> Just one question. Patch #1 is still under review and there will >>>> probably be further changes in the future. If I have patch #2 on the >>>> same branch and commit changes to patch #1 again later with "git commit >>>> -a --amend", wouldn't patch #2 be included in patch #1, too? >>> >>> git commit --amend edits topmost patch, i.e. #2, instead of #1 >>> >>> So if you make changes for #1 you need to create new commit #3, and squash >>> #3 and #1 with git rebase -i >>> >>>>>> Cheers >>>>>> >>>>>> Samuel >>>>>> , >>>>>> >>>>>> ---------------------------------------- >>>>>> >>>>>> Development mailing list >>>>>> Development at qt-project.org >>>>>> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From annulen at yandex.ru Mon Jan 22 13:30:10 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 22 Jan 2018 15:30:10 +0300 Subject: [Development] how to include further changes while previous commit is still under review? In-Reply-To: References: <27F59684-3E21-47DB-806E-E6A015D6095A@edeltech.ch> <3094321516383607@web41g.yandex.ru> <2044701516487293@web40g.yandex.ru> , <614061516617095@web53j.yandex.ru> , <120031516620998@web5o.yandex.ru> Message-ID: <974431516624210@web53o.yandex.ru> 22.01.2018, 14:47, "Martin Smith" : >> You are doing it wrong. In rebase -i menu don't reorder anything, instead >> mark commits for edit > > But then you have to do the editing with the rebase paused and then continue the rebase. I feel less anxiety reordering the picks and completing the rebase before beginning the editing. There is no reason to be anxious. * You can abort rebase at any time and restore previous state via git rebase --abort * You can restore any intermediate states via git reflog Not to mention that it's not always possible to reorder sequential commits without conflicts > > martin > > ________________________________________ > From: Konstantin Tokarev > Sent: Monday, January 22, 2018 12:36:38 PM > To: Martin Smith; Daniel Savi; Samuel Gaist > Cc: development at qt-project.org > Subject: Re: [Development] how to include further changes while previous commit is still under review? > > 22.01.2018, 14:34, "Martin Smith" : >>  When updating the documentation, I often do 2 or more different commits and pushes to a single branch. Then I wait for them to get approved. Often, a reviewer will require changes to the first pushed commit after I have pushed the second commit. Then I do: >> >>  git rebase -i HEAD~2 >> >>  ...and I reorder the "pick" lines. This makes the first commit accessible with: >> >>  git commit --amend >> >>  ...so I make the changes, use git add to make them visible to git commit --amend > > You are doing it wrong. In rebase -i menu don't reorder anything, instead mark commits for edit > >>  martin >> >>  ________________________________________ >>  From: Development on behalf of Konstantin Tokarev >>  Sent: Monday, January 22, 2018 11:31:35 AM >>  To: Daniel Savi; Samuel Gaist >>  Cc: development at qt-project.org >>  Subject: Re: [Development] how to include further changes while previous commit is still under review? >> >>  22.01.2018, 09:34, "Daniel Savi" : >>>   After reading some of the excellent documentation on git-scm.com, I'm planning to create two branches, one for patch 1 and one for patch 2. So, I would do "git branch fix1", "git checkout fix1", add some changes from review, "git commit --amend", then "git checkout master", "git branch fix2", git checkout fix2", add fix 2 and commit the second patch. I'm writing all commands by heart, may have some mistakes there. >>>   Would that work out, or am I running into troubles somewhere? >> >>  1. "git branch fix1", "git checkout fix1" is usually done in one step: git checkout -b fix1 >>  2. Yes, this is going to work, and moreover, it's probably the best approach from theoretic point of view, also known as "feature branches". What I've suggested is a pragmatic shortcut, to avoid switching branches and therefore save a bit of time by avoid excessive file rewrites and following recompilation. >> >>>   Am 20. Januar 2018 23:28:13 MEZ schrieb Konstantin Tokarev : >>>>   21.01.2018, 01:25, "Daniel Savi" : On 19.01.2018 18:40, Konstantin Tokarev wrote: 19.01.2018, 01:58, "Samuel Gaist" : On 18 Jan 2018, at 22:42, Daniel Savi wrote: Hello qt devs I'm back with another newbie question. I have committed a patch that is still under review on gerrit. Meanwhile, I've got a local and unrelated patch on the same file, that I would like to commit, too. Now, how would I include this patch into my local git repo and how would I commit it as a separate patch to the first? How could I still work on the first patch, once more comments are coming in? Would I create separate branches? Sorry for my very basic level of git-foo. >>>>>>>>   ---------------------------------------- >>>>>>>> >>>>>>>>      Development mailing list >>>>>>>>      Development at qt-project.org >>>>>>>>      http://lists.qt-project.org/mailman/listinfo/development >>>>>>>    Hi, >>>>>>> >>>>>>>    Since the patch is unrelated, use a different topic branch for that one and submit it like the other one. >>>>>>> >>>>>>>    Depending on the impact of your change, you might want to look at https://git-scm.com/docs/git-worktree and have a separate build for it. >>>>> >>>>>   I will read that, thank you for the link. >>>>>>    I think it's OK to create it in the same branch with previous one, especially in this case when patches touch same file >>>>>>    and there is a non-zero probability of conflict because of order change. >>>>>> >>>>>>    While patch #2 will have #1 shown in Gerrit as a "dependency", they still can be integrated separately from each other (if #2 does actually apply to the branch without #1). >>>>> >>>>>   Just one question. Patch #1 is still under review and there will >>>>>   probably be further changes in the future. If I have patch #2 on the >>>>>   same branch and commit changes to patch #1 again later with "git commit >>>>>   -a --amend", wouldn't patch #2 be included in patch #1, too? >>>> >>>>   git commit --amend edits topmost patch, i.e. #2, instead of #1 >>>> >>>>   So if you make changes for #1 you need to create new commit #3, and squash >>>>   #3 and #1 with git rebase -i >>>> >>>>>>>    Cheers >>>>>>> >>>>>>>    Samuel >>>>>>>    , >>>>>>> >>>>>>>   ---------------------------------------- >>>>>>> >>>>>>>    Development mailing list >>>>>>>    Development at qt-project.org >>>>>>>    http://lists.qt-project.org/mailman/listinfo/development >> >>  -- >>  Regards, >>  Konstantin >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin --  Regards, Konstantin From Martin.Smith at qt.io Mon Jan 22 14:50:56 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 22 Jan 2018 13:50:56 +0000 Subject: [Development] how to include further changes while previous commit is still under review? In-Reply-To: <974431516624210@web53o.yandex.ru> References: <27F59684-3E21-47DB-806E-E6A015D6095A@edeltech.ch> <3094321516383607@web41g.yandex.ru> <2044701516487293@web40g.yandex.ru> , <614061516617095@web53j.yandex.ru> , <120031516620998@web5o.yandex.ru> , <974431516624210@web53o.yandex.ru> Message-ID: >Not to mention that it's not always possible to reorder sequential commits >without conflicts That would mean changes to the same file in different commits. But that would have been already handled with a git commit --amend using pick reordering. martin ________________________________________ From: Konstantin Tokarev Sent: Monday, January 22, 2018 1:30:10 PM To: Martin Smith; Daniel Savi; Samuel Gaist Cc: development at qt-project.org Subject: Re: [Development] how to include further changes while previous commit is still under review? 22.01.2018, 14:47, "Martin Smith" : >> You are doing it wrong. In rebase -i menu don't reorder anything, instead >> mark commits for edit > > But then you have to do the editing with the rebase paused and then continue the rebase. I feel less anxiety reordering the picks and completing the rebase before beginning the editing. There is no reason to be anxious. * You can abort rebase at any time and restore previous state via git rebase --abort * You can restore any intermediate states via git reflog Not to mention that it's not always possible to reorder sequential commits without conflicts > > martin > > ________________________________________ > From: Konstantin Tokarev > Sent: Monday, January 22, 2018 12:36:38 PM > To: Martin Smith; Daniel Savi; Samuel Gaist > Cc: development at qt-project.org > Subject: Re: [Development] how to include further changes while previous commit is still under review? > > 22.01.2018, 14:34, "Martin Smith" : >> When updating the documentation, I often do 2 or more different commits and pushes to a single branch. Then I wait for them to get approved. Often, a reviewer will require changes to the first pushed commit after I have pushed the second commit. Then I do: >> >> git rebase -i HEAD~2 >> >> ...and I reorder the "pick" lines. This makes the first commit accessible with: >> >> git commit --amend >> >> ...so I make the changes, use git add to make them visible to git commit --amend > > You are doing it wrong. In rebase -i menu don't reorder anything, instead mark commits for edit > >> martin >> >> ________________________________________ >> From: Development on behalf of Konstantin Tokarev >> Sent: Monday, January 22, 2018 11:31:35 AM >> To: Daniel Savi; Samuel Gaist >> Cc: development at qt-project.org >> Subject: Re: [Development] how to include further changes while previous commit is still under review? >> >> 22.01.2018, 09:34, "Daniel Savi" : >>> After reading some of the excellent documentation on git-scm.com, I'm planning to create two branches, one for patch 1 and one for patch 2. So, I would do "git branch fix1", "git checkout fix1", add some changes from review, "git commit --amend", then "git checkout master", "git branch fix2", git checkout fix2", add fix 2 and commit the second patch. I'm writing all commands by heart, may have some mistakes there. >>> Would that work out, or am I running into troubles somewhere? >> >> 1. "git branch fix1", "git checkout fix1" is usually done in one step: git checkout -b fix1 >> 2. Yes, this is going to work, and moreover, it's probably the best approach from theoretic point of view, also known as "feature branches". What I've suggested is a pragmatic shortcut, to avoid switching branches and therefore save a bit of time by avoid excessive file rewrites and following recompilation. >> >>> Am 20. Januar 2018 23:28:13 MEZ schrieb Konstantin Tokarev : >>>> 21.01.2018, 01:25, "Daniel Savi" : On 19.01.2018 18:40, Konstantin Tokarev wrote: 19.01.2018, 01:58, "Samuel Gaist" : On 18 Jan 2018, at 22:42, Daniel Savi wrote: Hello qt devs I'm back with another newbie question. I have committed a patch that is still under review on gerrit. Meanwhile, I've got a local and unrelated patch on the same file, that I would like to commit, too. Now, how would I include this patch into my local git repo and how would I commit it as a separate patch to the first? How could I still work on the first patch, once more comments are coming in? Would I create separate branches? Sorry for my very basic level of git-foo. >>>>>>>> ---------------------------------------- >>>>>>>> >>>>>>>> Development mailing list >>>>>>>> Development at qt-project.org >>>>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>>>> Hi, >>>>>>> >>>>>>> Since the patch is unrelated, use a different topic branch for that one and submit it like the other one. >>>>>>> >>>>>>> Depending on the impact of your change, you might want to look at https://git-scm.com/docs/git-worktree and have a separate build for it. >>>>> >>>>> I will read that, thank you for the link. >>>>>> I think it's OK to create it in the same branch with previous one, especially in this case when patches touch same file >>>>>> and there is a non-zero probability of conflict because of order change. >>>>>> >>>>>> While patch #2 will have #1 shown in Gerrit as a "dependency", they still can be integrated separately from each other (if #2 does actually apply to the branch without #1). >>>>> >>>>> Just one question. Patch #1 is still under review and there will >>>>> probably be further changes in the future. If I have patch #2 on the >>>>> same branch and commit changes to patch #1 again later with "git commit >>>>> -a --amend", wouldn't patch #2 be included in patch #1, too? >>>> >>>> git commit --amend edits topmost patch, i.e. #2, instead of #1 >>>> >>>> So if you make changes for #1 you need to create new commit #3, and squash >>>> #3 and #1 with git rebase -i >>>> >>>>>>> Cheers >>>>>>> >>>>>>> Samuel >>>>>>> , >>>>>>> >>>>>>> ---------------------------------------- >>>>>>> >>>>>>> Development mailing list >>>>>>> Development at qt-project.org >>>>>>> http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Regards, >> Konstantin >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin -- Regards, Konstantin From rithvikp98 at gmail.com Mon Jan 22 14:53:55 2018 From: rithvikp98 at gmail.com (Rithvik Patibandla) Date: Mon, 22 Jan 2018 19:23:55 +0530 Subject: [Development] Integrating Common Print Dialog project into Qt In-Reply-To: <72694F34-82A3-48D6-A47A-B46B07611B82@gmail.com> References: <72694F34-82A3-48D6-A47A-B46B07611B82@gmail.com> Message-ID: On Thursday 21 December 2017 02:35 PM, Rithvik Patibandla wrote: > 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 Hi, After input from Qt developers (both on this thread and outside), I modified the UI part of the dialog and redid it using qwidgets instead of qt quick. The new code can be found here: https://github.com/rithvikp1998/CPDv2 The code is only half-complete but the basic skeleton is ready and we need as much input (regarding the code structure etc.) that we can get from the qt community in order for this dialog to make it into the official qt API. Thanks, Rithvik From mardy at users.sourceforge.net Mon Jan 22 16:36:54 2018 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Mon, 22 Jan 2018 18:36:54 +0300 Subject: [Development] Using native webview on OS X Message-ID: Hi all! I've developed a desktop application which uses the WebView QML module, with the hope of publishing it in the Apple store. However, unless I am seriously mistaken, this is just not possible (or maybe the documentation needs some serious love). No matter what I try, it seems that QtWebEngine is always required! If I simply remove QtWebEngine from my Qt installation, building the application succeeds but then when I run it I get the same error as in https://bugreports.qt.io/browse/QTBUG-63107 If I look at src/webview/qtwebviewfunctions.cpp it looks like the decision to use the native webview vs QtWebEngine is done at runtime, but for some reason it looks like one still needs to have QtWebEngine available in order for QtWebView to build successfully. With the obvious consequence that one won't be able to publish one's app into the Apple store. Is there some reason why the QtWebEngine support library isn't dlopen'ed at runtime? Can I file a bug about that? Ciao, Alberto From annulen at yandex.ru Mon Jan 22 16:49:36 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 22 Jan 2018 18:49:36 +0300 Subject: [Development] Using native webview on OS X In-Reply-To: References: Message-ID: <593911516636176@web39j.yandex.ru> 22.01.2018, 18:37, "Alberto Mardegan" : > Hi all! >   I've developed a desktop application which uses the WebView QML > module, with the hope of publishing it in the Apple store. However, > unless I am seriously mistaken, this is just not possible (or maybe the > documentation needs some serious love). > > No matter what I try, it seems that QtWebEngine is always required! > > If I simply remove QtWebEngine from my Qt installation, building the > application succeeds but then when I run it I get the same error as in > https://bugreports.qt.io/browse/QTBUG-63107 > > If I look at src/webview/qtwebviewfunctions.cpp it looks like the > decision to use the native webview vs QtWebEngine is done at runtime, > but for some reason it looks like one still needs to have QtWebEngine > available in order for QtWebView to build successfully. With the obvious > consequence that one won't be able to publish one's app into the Apple > store. > > Is there some reason why the QtWebEngine support library isn't dlopen'ed > at runtime? Can I file a bug about that? >From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable is required to use native backend. [1] https://codereview.qt-project.org/#/c/162337/ > > Ciao, >   Alberto > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From mardy at users.sourceforge.net Mon Jan 22 18:22:50 2018 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Mon, 22 Jan 2018 20:22:50 +0300 Subject: [Development] Using native webview on OS X In-Reply-To: <593911516636176@web39j.yandex.ru> References: <593911516636176@web39j.yandex.ru> Message-ID: On 22/01/2018 18:49, Konstantin Tokarev wrote: > From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable > is required to use native backend. > > [1] https://codereview.qt-project.org/#/c/162337/ Yes, but still QtWebEngine is required, as QtWebView is linking to it. I've now removed a few lines of code here and there and got a version of QtWebView which builds fine under macos without being linked to QtWebEngine. I'll soon try to see if it actually works. Ciao, Alberto From thiago.macieira at intel.com Mon Jan 22 19:39:51 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 Jan 2018 10:39:51 -0800 Subject: [Development] API review request: CBOR Stream reader and writer In-Reply-To: <2775239.o9DK0cSrxL@tjmaciei-mobl1> References: <2363292.KCnvKgr5nM@tjmaciei-mobl1> <2775239.o9DK0cSrxL@tjmaciei-mobl1> Message-ID: <9194432.D7LHNr2tFt@tjmaciei-mobl1> On segunda-feira, 22 de janeiro de 2018 01:37:40 PST Thiago Macieira wrote: > CBOR parsing: > 341,311535 task-clock > 885.053.081 cycles > 2.548.803.851 instructions > > The string parser is still showing up at 70.5% of the full execution time, > of which 33.4% are in QCborStreamReader and 20.4% calling isValidUtf8(). > The program spends 25,0% inside QIODevice, inside the string decoder. > Unlike the JSON parser, we don't operate on a pre-read byte array, but > directly on the QIODevice, checking for size. I've further optimised isValidUtf8() and now the string parser is only 61% of the execution time, with isValidUtf8() down to 7.7%. https://codereview.qt-project.org/217084 for the optimisations. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jan 23 01:56:56 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 Jan 2018 16:56:56 -0800 Subject: [Development] API review request: CBOR Stream reader and writer In-Reply-To: <2775239.o9DK0cSrxL@tjmaciei-mobl1> References: <2363292.KCnvKgr5nM@tjmaciei-mobl1> <2775239.o9DK0cSrxL@tjmaciei-mobl1> Message-ID: <4079703.qoYkzmZbfb@tjmaciei-mobl1> On segunda-feira, 22 de janeiro de 2018 01:37:40 PST Thiago Macieira wrote: > Binary JSON validating: > 97,003559 task-clock:u (msec) > 237.092.857 cycles > 437.005.872 instructions > [15.2% was spent in QIODevice::readAll, 59.1% in fromBinaryData] > > JSON parsing: > 273,359723 task-clock:u (msec) > 793.297.513 cycles > 2.698.607.303 instructions > [4.7% in readAll(), 78.2% in fromJson] > > CBOR parsing: > 341,311535 task-clock > 885.053.081 cycles > 2.548.803.851 instructions After fixing the converter example to properly use mmap in all three cases, plus refactoring the CBOR parser to operate on a pre-loaded array and use larger buffer than single-digit byte counts, the numbers are: Binary JSON: 69,844846 task-clock:u (msec) 196.906.259 cycles:u 422.255.714 instructions:u [There's no readAll(); 70.2% of the time is spent inside QJsonPrivate::Object::isValid] JSON: 255,809132 task-clock:u (msec) 771.771.000 cycles:u 2.690.966.058 instructions:u [80.2% inside QJsonPrivate::Parser::parseValue, 58.7% inside QJsonPrivate::Parser::parseString and 16.3% inside QUtf8Functions::fromUtf8] CBOR: 239,059121 task-clock:u (msec) 562.474.857 cycles:u 1.431.590.428 instructions:u [71.6% inside QCborValue::fromCbor, 65.0% inside QCborContainerPrivate::decodeStringFromCbor, 25.5% inside QCborStreamReader::readStringChunk plus 12.6% inside QUtf8::isValidUtf8] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jan 23 02:45:09 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 Jan 2018 17:45:09 -0800 Subject: [Development] API review request: CBOR Stream reader and writer In-Reply-To: <4079703.qoYkzmZbfb@tjmaciei-mobl1> References: <2363292.KCnvKgr5nM@tjmaciei-mobl1> <2775239.o9DK0cSrxL@tjmaciei-mobl1> <4079703.qoYkzmZbfb@tjmaciei-mobl1> Message-ID: <3813369.J7RTUFqC7S@tjmaciei-mobl1> On segunda-feira, 22 de janeiro de 2018 16:56:56 PST Thiago Macieira wrote: > After fixing the converter example to properly use mmap in all three cases, > plus refactoring the CBOR parser to operate on a pre-loaded array and use > larger buffer than single-digit byte counts, the numbers are: A major difference between the three is the memory allocation strategy. The Binary JSON needs none, since it uses an in-memory format for the on-disk format. So the application runs with 53880 kB of the mmapped file in a total of 64384 kB RSS. The parsed QJsonDocument uses the same allocation strategy, which one if its greatest advantages. It allocates a buffer equal to the size of the JSON input, so after unloading the 55872 kB of the source file, it keeps a huge block of 55792 kB allocated, in a total of 65928 kB RSS. A major drawback of this is that the Binary JSON memory format is limited to 128 MB in total. There's a bug report about this and changing the format to raise this limit, even for in-memory, will change the numbers above. QCborValue does no such thing, but it's also not limited. Since it uses regular memory allocation, after unloading the 40244 kB file, it needs 110356 kB of heap, for a total of 120428 kB RSS. For comparison, loading the same data from a QDataStream and keeping in a QVariant requires 233944 kB of heap, for a total of 244088 kB RSS. The QDataStream file is 76156 kB and that includes all strings stored as UTF-16, so it's not the UTF-16 vs UTF-8 vs Latin1 that accounts for the majority of the overhead. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Tue Jan 23 13:49:59 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 23 Jan 2018 12:49:59 +0000 Subject: [Development] Qt 5.9.4 released Message-ID: Hi, We have released Qt 5.9.4 today, see http://blog.qt.io/blog/2018/01/23/qt-5-9-4-released/ Big thanks for everyone involved! br, Jani Heikkinen Release Manager From Morten.Sorvig at qt.io Tue Jan 23 15:09:02 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Tue, 23 Jan 2018 14:09:02 +0000 Subject: [Development] Using native webview on OS X In-Reply-To: References: <593911516636176@web39j.yandex.ru> Message-ID: <3ED7650A-6799-46F5-A972-6861F8EE9323@qt.io> > On 22 Jan 2018, at 18:22, Alberto Mardegan wrote: > > On 22/01/2018 18:49, Konstantin Tokarev wrote: >> From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable >> is required to use native backend. >> >> [1] https://codereview.qt-project.org/#/c/162337/ > > Yes, but still QtWebEngine is required, as QtWebView is linking to it. > I've now removed a few lines of code here and there and got a version of > QtWebView which builds fine under macos without being linked to QtWebEngine. > I'll soon try to see if it actually works. > > Ciao, > Alberto The QtWebEngine requirement does seem to run counter to the purpose of the QtWebView module. It’s not really clear from the history what happened, but I think we can restore the original behavior: https://codereview.qt-project.org/#/c/217706/ Morten From annulen at yandex.ru Tue Jan 23 15:11:52 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 23 Jan 2018 17:11:52 +0300 Subject: [Development] Using native webview on OS X In-Reply-To: <3ED7650A-6799-46F5-A972-6861F8EE9323@qt.io> References: <593911516636176@web39j.yandex.ru> <3ED7650A-6799-46F5-A972-6861F8EE9323@qt.io> Message-ID: <14241516716712@web18o.yandex.ru> 23.01.2018, 17:09, "Morten Sørvig" : >>  On 22 Jan 2018, at 18:22, Alberto Mardegan wrote: >> >>  On 22/01/2018 18:49, Konstantin Tokarev wrote: >>>  From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable >>>  is required to use native backend. >>> >>>  [1] https://codereview.qt-project.org/#/c/162337/ >> >>  Yes, but still QtWebEngine is required, as QtWebView is linking to it. >>  I've now removed a few lines of code here and there and got a version of >>  QtWebView which builds fine under macos without being linked to QtWebEngine. >>  I'll soon try to see if it actually works. >> >>  Ciao, >>   Alberto > > The QtWebEngine requirement does seem to run counter to the purpose of the QtWebView module. > > It’s not really clear from the history what happened, but I think we can restore the original behavior: > > https://codereview.qt-project.org/#/c/217706/ There was a discussion about run-time plugins in QtWebView, if they were implemented it won't be a problem to load and use QtWebEngine backend if it is really needed, and avoid it otherwise > > Morten -- Regards, Konstantin From mitch.curtis at qt.io Wed Jan 24 11:13:50 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Wed, 24 Jan 2018 10:13:50 +0000 Subject: [Development] #pragma once Message-ID: Why don't we use #pragma once in Qt like Qt Creator does? If it's due to old compilers that we have to support, which ones are the problem? - Someone who just spent too much time looking at a confusing compiler error caused by duplicated include guards. From nassian at bitshift-dynamics.com Wed Jan 24 11:22:23 2018 From: nassian at bitshift-dynamics.com (Alexander Nassian) Date: Wed, 24 Jan 2018 11:22:23 +0100 Subject: [Development] #pragma once In-Reply-To: References: Message-ID: Maybe because it’s not part of the C++ standard? Beste Grüße / Best regards, Alexander Nassian > Am 24.01.2018 um 11:13 schrieb Mitch Curtis : > > Why don't we use #pragma once in Qt like Qt Creator does? If it's due to old compilers that we have to support, which ones are the problem? > > - Someone who just spent too much time looking at a confusing compiler error caused by duplicated include guards. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: info at bitshift-dynamics.com Technischer Support: support at bitshift-dynamics.com Buchhaltung: invoice at bitshift-dynamics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ville.voutilainen at gmail.com Wed Jan 24 11:25:14 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 24 Jan 2018 12:25:14 +0200 Subject: [Development] #pragma once In-Reply-To: References: Message-ID: On 24 January 2018 at 12:22, Alexander Nassian wrote: > Maybe because it’s not part of the C++ standard? #pragma once is not a replacement for include guards. It's not part of the C++ standard because it doesn't always work, and modules are a superior solution anyway. From mitch.curtis at qt.io Wed Jan 24 11:34:05 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Wed, 24 Jan 2018 10:34:05 +0000 Subject: [Development] #pragma once In-Reply-To: References: Message-ID: > -----Original Message----- > From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] > Sent: Wednesday, 24 January 2018 11:25 AM > To: Alexander Nassian > Cc: Mitch Curtis ; development at qt-project.org > Subject: Re: [Development] #pragma once > > On 24 January 2018 at 12:22, Alexander Nassian dynamics.com> wrote: > > Maybe because it’s not part of the C++ standard? > > #pragma once is not a replacement for include guards. Why not? > It's not part of the C++ standard because it doesn't always work In which ways? My quick search gave me these: https://stackoverflow.com/a/1946730/904422 https://en.wikipedia.org/wiki/Pragma_once#Caveats There's also this answer that highly recommends against it, but seems quite contended in the comments: https://stackoverflow.com/a/34884735/904422 > and modules are a superior solution anyway. How so? From jeanmichael.celerier at gmail.com Wed Jan 24 12:32:36 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Wed, 24 Jan 2018 12:32:36 +0100 Subject: [Development] #pragma once In-Reply-To: References: Message-ID: I certainly have been bitten much more times by include guards that were the same in different files (especially in old libraries where guards look like #ifdef QUEUE_H because of course there is a single queue.h file in the whole world, or because someone just copy-pasted the content of a file to another and forgot changing include guards -- I plead guilty!) than whatever hypothetic bug in pragma once GCC's implementation may have. Are there people here who had, just once, a bug due to #pragma once ? I never met any. Across network drives, with precompiled headers, unity builds, with MSVC, Clang, GCC, ccache, distcc and Icecream... ------- Jean-Michaël Celerier http://www.jcelerier.name On Wed, Jan 24, 2018 at 11:34 AM, Mitch Curtis wrote: > > > > -----Original Message----- > > From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] > > Sent: Wednesday, 24 January 2018 11:25 AM > > To: Alexander Nassian > > Cc: Mitch Curtis ; development at qt-project.org > > Subject: Re: [Development] #pragma once > > > > On 24 January 2018 at 12:22, Alexander Nassian > dynamics.com> wrote: > > > Maybe because it’s not part of the C++ standard? > > > > #pragma once is not a replacement for include guards. > > Why not? > > > It's not part of the C++ standard because it doesn't always work > > In which ways? My quick search gave me these: > > https://stackoverflow.com/a/1946730/904422 > https://en.wikipedia.org/wiki/Pragma_once#Caveats > > There's also this answer that highly recommends against it, but seems > quite contended in the comments: > > https://stackoverflow.com/a/34884735/904422 > > > and modules are a superior solution anyway. > > How so? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nassian at bitshift-dynamics.com Wed Jan 24 12:39:05 2018 From: nassian at bitshift-dynamics.com (Alexander Nassian) Date: Wed, 24 Jan 2018 12:39:05 +0100 Subject: [Development] #pragma once In-Reply-To: References: Message-ID: <808E7545-1E93-4117-BBDE-5F3C71C5DF78@bitshift-dynamics.com> Besides its possible flaws, it‘s simply nothing that the C++ standard defines. I also want to use some glibc features that maybe also commonly available but it is still not standard, even worse, the implementation is completely userdefined. That same discussion raises up once a year about STL containers and others and then some compiler proves that Qt‘s way is the better by introducing some kind of bug or binary incompatibility. Beste Grüße / Best regards, Alexander Nassian > Am 24.01.2018 um 12:32 schrieb Jean-Michaël Celerier : > > I certainly have been bitten much more times by include guards that were the same in different files (especially in old libraries where guards look like #ifdef QUEUE_H because of course there is a single queue.h file in the whole world, or because someone just copy-pasted the content of a file to another and forgot changing include guards -- I plead guilty!) than whatever hypothetic bug in pragma once GCC's implementation may have. > > Are there people here who had, just once, a bug due to #pragma once ? I never met any. Across network drives, with precompiled headers, unity builds, with MSVC, Clang, GCC, ccache, distcc and Icecream... > > > > ------- > Jean-Michaël Celerier > http://www.jcelerier.name > >> On Wed, Jan 24, 2018 at 11:34 AM, Mitch Curtis wrote: >> >> >> > -----Original Message----- >> > From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] >> > Sent: Wednesday, 24 January 2018 11:25 AM >> > To: Alexander Nassian >> > Cc: Mitch Curtis ; development at qt-project.org >> > Subject: Re: [Development] #pragma once >> > >> > On 24 January 2018 at 12:22, Alexander Nassian > > dynamics.com> wrote: >> > > Maybe because it’s not part of the C++ standard? >> > >> > #pragma once is not a replacement for include guards. >> >> Why not? >> >> > It's not part of the C++ standard because it doesn't always work >> >> In which ways? My quick search gave me these: >> >> https://stackoverflow.com/a/1946730/904422 >> https://en.wikipedia.org/wiki/Pragma_once#Caveats >> >> There's also this answer that highly recommends against it, but seems quite contended in the comments: >> >> https://stackoverflow.com/a/34884735/904422 >> >> > and modules are a superior solution anyway. >> >> How so? >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: info at bitshift-dynamics.com Technischer Support: support at bitshift-dynamics.com Buchhaltung: invoice at bitshift-dynamics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed Jan 24 12:53:18 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 24 Jan 2018 14:53:18 +0300 Subject: [Development] #pragma once In-Reply-To: References: Message-ID: <679591516794798@web16o.yandex.ru> 24.01.2018, 14:33, "Jean-Michaël Celerier" : > I certainly have been bitten much more times by include guards that were the same in different files (especially in old libraries where guards look like #ifdef QUEUE_H because of course there is a single queue.h file in the whole world, or because someone just copy-pasted the content of a file to another and forgot changing include guards -- I plead guilty!) than whatever hypothetic bug in pragma once GCC's implementation may have. > > Are there people here who had, just once, a bug due to #pragma once ? I never met any. Across network drives, with precompiled headers, unity builds, with MSVC, Clang, GCC, ccache, distcc and Icecream... It is possible to get beaten by double inclusion if any headers are copied somewhere in the build process. We've stumbled upon this in WebKit project, where Windows-based ports are copying headers instead of merely creating forwarding ones (because of specifics of Apple's internal build process). Compiler believes that different files are different headers, so happily includes both when it gets a chance [1] That's said, if headers are never copied it's safer to use #pragma once than include guards [1] http://mac-os-forge.2317878.n4.nabble.com/unified-sources-build-forwarding-headers-that-are-copies-td348352.html > > ------- > Jean-Michaël Celerier > http://www.jcelerier.name > > On Wed, Jan 24, 2018 at 11:34 AM, Mitch Curtis wrote: > >>> -----Original Message----- >>> From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] >>> Sent: Wednesday, 24 January 2018 11:25 AM >>> To: Alexander Nassian >>> Cc: Mitch Curtis ; development at qt-project.org >>> Subject: Re: [Development] #pragma once >>> >>> On 24 January 2018 at 12:22, Alexander Nassian >> dynamics.com> wrote: >>> > Maybe because it’s not part of the C++ standard? >>> >>> #pragma once is not a replacement for include guards. >> >> Why not? >> >>> It's not part of the C++ standard because it doesn't always work >> >> In which ways? My quick search gave me these: >> >> https://stackoverflow.com/a/1946730/904422 >> https://en.wikipedia.org/wiki/Pragma_once#Caveats >> >> There's also this answer that highly recommends against it, but seems quite contended in the comments: >> >> https://stackoverflow.com/a/34884735/904422 >> >>> and modules are a superior solution anyway. >> >> How so? >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From ville.voutilainen at gmail.com Wed Jan 24 13:10:55 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 24 Jan 2018 14:10:55 +0200 Subject: [Development] #pragma once In-Reply-To: References: Message-ID: On 24 January 2018 at 12:34, Mitch Curtis wrote: > > >> -----Original Message----- >> From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] >> Sent: Wednesday, 24 January 2018 11:25 AM >> To: Alexander Nassian >> Cc: Mitch Curtis ; development at qt-project.org >> Subject: Re: [Development] #pragma once >> >> On 24 January 2018 at 12:22, Alexander Nassian > dynamics.com> wrote: >> > Maybe because it’s not part of the C++ standard? >> >> #pragma once is not a replacement for include guards. > > Why not? > >> It's not part of the C++ standard because it doesn't always work > > In which ways? My quick search gave me these: > > https://stackoverflow.com/a/1946730/904422 > https://en.wikipedia.org/wiki/Pragma_once#Caveats That wikipedia link seems to describe the problems fairly accurately. >> and modules are a superior solution anyway. > How so? Because you can import the same module multiple times without concerns about re-definitions, and that import is much faster than parsing a header file. From mitch.curtis at qt.io Wed Jan 24 13:19:41 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Wed, 24 Jan 2018 12:19:41 +0000 Subject: [Development] #pragma once In-Reply-To: References: Message-ID: > -----Original Message----- > From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] > Sent: Wednesday, 24 January 2018 1:11 PM > To: Mitch Curtis > Cc: Alexander Nassian ; development at qt- > project.org > Subject: Re: [Development] #pragma once > > On 24 January 2018 at 12:34, Mitch Curtis wrote: > > > > > >> -----Original Message----- > >> From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] > >> Sent: Wednesday, 24 January 2018 11:25 AM > >> To: Alexander Nassian > >> Cc: Mitch Curtis ; development at qt-project.org > >> Subject: Re: [Development] #pragma once > >> > >> On 24 January 2018 at 12:22, Alexander Nassian >> dynamics.com> wrote: > >> > Maybe because it’s not part of the C++ standard? > >> > >> #pragma once is not a replacement for include guards. > > > > Why not? > > > >> It's not part of the C++ standard because it doesn't always work > > > > In which ways? My quick search gave me these: > > > > https://stackoverflow.com/a/1946730/904422 > > https://en.wikipedia.org/wiki/Pragma_once#Caveats > > That wikipedia link seems to describe the problems fairly accurately. Do we have that issue in Qt? > >> and modules are a superior solution anyway. > > How so? > > Because you can import the same module multiple times without concerns > about re-definitions, and that import is much faster than parsing a header > file. From ville.voutilainen at gmail.com Wed Jan 24 13:24:07 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 24 Jan 2018 14:24:07 +0200 Subject: [Development] #pragma once In-Reply-To: References: Message-ID: On 24 January 2018 at 14:19, Mitch Curtis wrote: >> > https://en.wikipedia.org/wiki/Pragma_once#Caveats >> >> That wikipedia link seems to describe the problems fairly accurately. > > Do we have that issue in Qt? I do not anticipate to like to debug it if we hit that issue in our CI, or in a customer use case, or other user use case. If you want to insist on using #pragma once, the sane way forward is to use it in conjunction with header guards, not instead of header guards. From ville.voutilainen at gmail.com Wed Jan 24 13:26:26 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 24 Jan 2018 14:26:26 +0200 Subject: [Development] #pragma once In-Reply-To: References: Message-ID: On 24 January 2018 at 14:24, Ville Voutilainen wrote: > On 24 January 2018 at 14:19, Mitch Curtis wrote: >>> > https://en.wikipedia.org/wiki/Pragma_once#Caveats >>> >>> That wikipedia link seems to describe the problems fairly accurately. >> >> Do we have that issue in Qt? > > I do not anticipate to like to debug it if we hit that issue in our > CI, or in a customer use case, or other user use case. > If you want to insist on using #pragma once, the sane way forward is > to use it in conjunction with header guards, not > instead of header guards. That, of course, means that #pragma once will not solve your original problem, because in order to avoid the problems of #pragma once, it needs to be inside the header guard. From tuukka.turunen at qt.io Wed Jan 24 14:41:01 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 24 Jan 2018 13:41:01 +0000 Subject: [Development] Change description of strict phase to match current practice Message-ID: <9B293B96-F74C-4998-8EC2-F205A804BF76@qt.io> Hi, I would like to change QUIP5 (Choosing a branch) slightly to match our current practice: https://codereview.qt-project.org/#/c/215712/ QUIP5 currently states: “*strict* This period starts when the subsequent stable branch is created (for the 5.6 LTS, this would have been 5.7).” This does not match what we did with Qt 5.6, as it would have meant that we enter cherry pick mode after three months. We did not do that with Qt 5.9 either, but continued to push all fixes through the LTS release after Qt 5.10 was branched from dev. I would propose new text for this to be: “*strict* This period starts when the one after next stable branch is created (for the 5.9 LTS, the one after next is 5.11).” This is a better match to our existing practice and also feasible from branch management viewpoint. If we would continue pushing everything via the LTS branch also when the one after next stable branch is created, it would soon become an impossible task due to the amount of merges needed. The change already has +2 in codereview, but before staging it, we would like to make sure this is a generally accepted change to the QUIP5. If you have objections, please tell about these either in the mailing list or in the change itself. Yours, Tuukka -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Jan 24 15:09:06 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Jan 2018 06:09:06 -0800 Subject: [Development] #pragma once In-Reply-To: <679591516794798@web16o.yandex.ru> References: <679591516794798@web16o.yandex.ru> Message-ID: <3530272.8kfmFglG1E@tjmaciei-mobl1> On Wednesday, 24 January 2018 03:53:18 PST Konstantin Tokarev wrote: > That's said, if headers are never copied it's safer to use #pragma once than > include guards And you know what copies headers? make install If you do an installed build of each module, then the compiler will have to add -I for the target as well as for the source dir. So if you build a module while that module is already installed, it will find the installed headers and include both. That said, I am not sure that type of build works anyway because of this very reason and that different library files will be present, causing linking errors too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed Jan 24 15:12:13 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 24 Jan 2018 17:12:13 +0300 Subject: [Development] #pragma once In-Reply-To: <3530272.8kfmFglG1E@tjmaciei-mobl1> References: <679591516794798@web16o.yandex.ru> <3530272.8kfmFglG1E@tjmaciei-mobl1> Message-ID: <43121516803133@web53j.yandex.ru> 24.01.2018, 17:09, "Thiago Macieira" : > On Wednesday, 24 January 2018 03:53:18 PST Konstantin Tokarev wrote: >>  That's said, if headers are never copied it's safer to use #pragma once than >>  include guards > > And you know what copies headers? make install > > If you do an installed build of each module, then the compiler will have to > add -I for the target as well as for the source dir. So if you build a module > while that module is already installed, it will find the installed headers and > include both. Indeed, I'm hitting this sometimes, when there is ABI break in private header > > That said, I am not sure that type of build works anyway because of this very > reason and that different library files will be present, causing linking > errors too. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From oswald.buddenhagen at qt.io Wed Jan 24 15:30:38 2018 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 24 Jan 2018 15:30:38 +0100 Subject: [Development] #pragma once In-Reply-To: <3530272.8kfmFglG1E@tjmaciei-mobl1> References: <679591516794798@web16o.yandex.ru> <3530272.8kfmFglG1E@tjmaciei-mobl1> Message-ID: <20180124143038.GA1436@troll08> On Wed, Jan 24, 2018 at 06:09:06AM -0800, Thiago Macieira wrote: > On Wednesday, 24 January 2018 03:53:18 PST Konstantin Tokarev wrote: > > That's said, if headers are never copied it's safer to use #pragma once than > > include guards > > And you know what copies headers? make install > > If you do an installed build of each module, then the compiler will have to > add -I for the target as well as for the source dir. So if you build a module > while that module is already installed, it will find the installed headers and > include both. > > That said, I am not sure that type of build works anyway because of this very > reason and that different library files will be present, causing linking > errors too. > of course this is not supposed to work. if the current source directory doesn't shadow the installation directory completely, that's a bug. there are some cases like that (because our build system sucks) and the only workaround for that is uninstalling the previous build. in fact, you're the one who always argued for that "solution" (even in the cases we eventually fixed). but that's only tangentially related to the issue at hand, because the compiler would still pick only one of the files under normal circumstances. a problem would arise if different include styles in different files lead to different headers being picked up from the same -I list. it's fairly hard to construct such a case, and it *probably* doesn't appear inside qt's "regular" build system (that specifically excludes webkit & webengine). From ville.voutilainen at gmail.com Wed Jan 24 16:19:55 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 24 Jan 2018 17:19:55 +0200 Subject: [Development] #pragma once In-Reply-To: <20180124143038.GA1436@troll08> References: <679591516794798@web16o.yandex.ru> <3530272.8kfmFglG1E@tjmaciei-mobl1> <20180124143038.GA1436@troll08> Message-ID: On 24 January 2018 at 16:30, Oswald Buddenhagen wrote: > but that's only tangentially related to the issue at hand, because the > compiler would still pick only one of the files under normal > circumstances. a problem would arise if different include styles in > different files lead to different headers being picked up from the same > -I list. it's fairly hard to construct such a case, and it *probably* > doesn't appear inside qt's "regular" build system (that specifically > excludes webkit & webengine). That risk is not worth taking. Get your include guards right, and don't mess with #pragma once. There are tools that can help, but I haven't used them myself, and I don't know whether clang has anything for this. From fromqt at tungware.se Wed Jan 24 17:30:49 2018 From: fromqt at tungware.se (Henry Skoglund) Date: Wed, 24 Jan 2018 17:30:49 +0100 Subject: [Development] #pragma once In-Reply-To: References: <679591516794798@web16o.yandex.ru> <3530272.8kfmFglG1E@tjmaciei-mobl1> <20180124143038.GA1436@troll08> Message-ID: <99e315a7-7856-e8d4-83af-9efa2df1ebdb@tungware.se> On 2018-01-24 16:19, Ville Voutilainen wrote: > On 24 January 2018 at 16:30, Oswald Buddenhagen > wrote: >> but that's only tangentially related to the issue at hand, because the >> compiler would still pick only one of the files under normal >> circumstances. a problem would arise if different include styles in >> different files lead to different headers being picked up from the same >> -I list. it's fairly hard to construct such a case, and it *probably* >> doesn't appear inside qt's "regular" build system (that specifically >> excludes webkit & webengine). > > > That risk is not worth taking. Get your include guards right, and > don't mess with #pragma once. > There are tools that can help, but I haven't used them myself, and I > don't know whether clang > has anything for this. > Thank you for this clarification. I always thought #pragma once is superior to include guards, but I didn't really realize that the compiler is dealing with two different kind of namespaces (filenames vs #defined names), which could cause those problems mentioned above. For exaample on Windows, if your're including files from a server/SMB-share, then I've seen sometimes the including files keep their drive letter, e.g P:\\dir\\file.h but sometimes it gets resolved into \\computername\\sharename\\dir\\file.h, and it's unclear if a #pragma once would treat those as the same file. Rgrds Henry From thiago.macieira at intel.com Wed Jan 24 19:49:32 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Jan 2018 10:49:32 -0800 Subject: [Development] API review request: CBOR Stream reader and writer In-Reply-To: <2363292.KCnvKgr5nM@tjmaciei-mobl1> References: <2363292.KCnvKgr5nM@tjmaciei-mobl1> Message-ID: <6173617.UlkAiaMggH@tjmaciei-mobl1> On Wednesday, 17 January 2018 13:25:53 PST Thiago Macieira wrote: > I'm also interested in what I could write as an example. Please send > suggestions. I've added a CBOR dump tool example, which can help you with understanding what you have: $ convert/convert -o line-wrap=no /tmp/test3.cbor { "Hello": false, "World": 1.2, "foo": [ 1.0, 2.0, 3.0 ] } $ convert/convert /tmp/test3.cbor { "Hello": false, "World": 1.2, "foo": [ 1.0, 2.0, 3.0 ] } $ cbordump/cbordump --compact /tmp/test3.cbor 55799({ "Hello": false, "World": 1.2, "foo": [ 1.0f, 2.0f, 3.0f ] }) $ cbordump/cbordump /tmp/test3.cbor 55799({ "Hello": false, "World": 1.2, "foo": [ 1.0f, 2.0f, 3.0f ] }) You may be asking why the two tools print different output. What's that 55799 and why do 1, 2 and 3 have "f" at the end? Well, the use the annotated mode: $ cbordump/cbordump --annotated /tmp/test3.cbor d9 d9 f7 # Tag 55799 (Self-describe CBOR; see Section 2.4.5 [RFC7049]) a3 # Map length 3 65 # Text string length 5 48 65 6c 6c 6f # "Hello" f4 # Simple Type false 65 # Text string length 5 57 6f 72 6c 64 # "World" fb 3f f3 33 33 33 33 33 33 # Double 1.2 63 # Text string length 3 66 6f 6f # "foo" 83 # Array length 3 fa 3f 80 00 00 # Float 1. fa 40 00 00 00 # Float 2. fa 40 40 00 00 # Float 3. That 55799 allows this: $ file /tmp/test3.cbor /tmp/test3.cbor: Concise Binary Object Representation (CBOR) container The "f" indicate that it's a float, not double. And just because I can: $ qtplugininfo --full-json $QTOBJDIR/plugins/sqldrivers/libqsqlmysql.so | \ ./convert/convert -O cbor -o signature=no | \ ./cbordump/cbordump --annotated a5 # Map length 5 63 # Text string length 3 49 49 44 # "IID" 78 2c # Text string length 44 6f 72 67 2e 71 74 2d 70 72 6f 6a 65 63 74 2e # "org.qt-project." 51 74 2e 51 53 71 6c 44 72 69 76 65 72 46 61 # "Qt.QSqlDriverFa" 63 74 6f 72 79 49 6e 74 65 72 66 61 63 65 # "ctoryInterface" 68 # Text string length 8 4d 65 74 61 44 61 74 61 # "MetaData" a1 # Map length 1 64 # Text string length 4 4b 65 79 73 # "Keys" 82 # Array length 2 67 # Text string length 7 51 4d 59 53 51 4c 33 # "QMYSQL3" 66 # Text string length 6 51 4d 59 53 51 4c # "QMYSQL" 69 # Text string length 9 63 6c 61 73 73 4e 61 6d 65 # "className" 72 # Text string length 18 51 4d 59 53 51 4c 44 72 69 76 65 72 50 6c 75 # "QMYSQLDriverPlu" 67 69 6e # "gin" 65 # Text string length 5 64 65 62 75 67 # "debug" f5 # Simple Type true 67 # Text string length 7 76 65 72 73 69 6f 6e # "version" 1a 00 05 0a 00 # Unsigned integer 0x50a00 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jan 24 20:45:00 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Jan 2018 11:45:00 -0800 Subject: [Development] API review request: CBOR Stream reader and writer In-Reply-To: <6173617.UlkAiaMggH@tjmaciei-mobl1> References: <2363292.KCnvKgr5nM@tjmaciei-mobl1> <6173617.UlkAiaMggH@tjmaciei-mobl1> Message-ID: <4151199.980E1kAjC2@tjmaciei-mobl1> On Wednesday, 24 January 2018 10:49:32 PST Thiago Macieira wrote: > I've added a CBOR dump tool example, which can help you with understanding > what you have: One more difference: since "convert" uses QCborValue, it will normalise a few items: $ ./convert/convert /tmp/test3.cbor [ 32("https://example.com/© "), 0("2018-01-10T06:24:37.000Z") ] $ ./cbordump/cbordump /tmp/test3.cbor [ 32("HTTPS://EXAMPLE.COM/%C2%A9 "), 1(1515565477) ] Note how there's information loss if you try to convert this to JSON: $ ./convert/convert -O json /tmp/test3.cbor [ "https://example.com/%C2%A9%20", "2018-01-10T06:24:37.000Z" ] [This was after change https://codereview.qt-project.org/217854 to QJsonValue] $ ./cbordump/cbordump --annotated /tmp/test3.cbor 82 # Array length 2 d8 20 # Tag 32 (URI; see Section 2.4.4.3 [RFC7049]) 78 1b # Text string length 27 48 54 54 50 53 3a 2f 2f 45 58 41 4d 50 4c # "HTTPS://EXAMPL" 45 2e 43 4f 4d 2f 25 43 32 25 41 39 20 # "E.COM/%C2%A9 " c1 # Tag 1 (Epoch-based date/ time; see Section 2.4.1 [RFC7049]) 1a 5a 55 b1 a5 # Unsigned integer 0x5a55b1a5 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Thu Jan 25 07:57:39 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 25 Jan 2018 06:57:39 +0000 Subject: [Development] Branching from 'dev' to '5.11' started Message-ID: Hi, We have now soft branched '5.11' from dev so please start using '5.11' now. Qt 5.11 feature freeze and final downmerge from 'dev' to '5.11' will happen Wed 31.1.2018 so there is still enough time to finalize ongoing changes in 'dev'. And let's keep the feature freeze now, it is key enabler for us to be able to keep the release schedule. So it is time to check if new feature can be finalized early enough for the feature freeze. If not then we should just postpone it to Qt 5.12 instead of trying to get it in Qt 5.11. br, Jani Heikkinen Release Manager From mathias at taschenorakel.de Thu Jan 25 11:27:07 2018 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Thu, 25 Jan 2018 11:27:07 +0100 Subject: [Development] #pragma once In-Reply-To: References: Message-ID: <0c012dab-5358-ced3-6fa6-804c2377095f@taschenorakel.de> Let's see what people who know much more about compiler features than any of us think about "#pragma once". Let's check what GCC and Clang do for their C++ library headers: $ grep -r pragma.*once /usr/include/clang/5.0.0/include /usr/include/c++/7.2.0/ $ ...and this is about headers that target exactly one compiler and are known to be locally installed. Hope this helps, Mathias Am 24.01.2018 um 13:19 schrieb Mitch Curtis: > > >> -----Original Message----- >> From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] >> Sent: Wednesday, 24 January 2018 1:11 PM >> To: Mitch Curtis >> Cc: Alexander Nassian ; development at qt- >> project.org >> Subject: Re: [Development] #pragma once >> >> On 24 January 2018 at 12:34, Mitch Curtis wrote: >>> >>> >>>> -----Original Message----- >>>> From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] >>>> Sent: Wednesday, 24 January 2018 11:25 AM >>>> To: Alexander Nassian >>>> Cc: Mitch Curtis ; development at qt-project.org >>>> Subject: Re: [Development] #pragma once >>>> >>>> On 24 January 2018 at 12:22, Alexander Nassian >>> dynamics.com> wrote: >>>>> Maybe because it’s not part of the C++ standard? >>>> >>>> #pragma once is not a replacement for include guards. >>> >>> Why not? >>> >>>> It's not part of the C++ standard because it doesn't always work >>> >>> In which ways? My quick search gave me these: >>> >>> https://stackoverflow.com/a/1946730/904422 >>> https://en.wikipedia.org/wiki/Pragma_once#Caveats >> >> That wikipedia link seems to describe the problems fairly accurately. > > Do we have that issue in Qt? > >>>> and modules are a superior solution anyway. >>> How so? >> >> Because you can import the same module multiple times without concerns >> about re-definitions, and that import is much faster than parsing a header >> file. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From annulen at yandex.ru Thu Jan 25 11:31:02 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 25 Jan 2018 13:31:02 +0300 Subject: [Development] #pragma once In-Reply-To: <0c012dab-5358-ced3-6fa6-804c2377095f@taschenorakel.de> References: <0c012dab-5358-ced3-6fa6-804c2377095f@taschenorakel.de> Message-ID: <2419731516876262@web32j.yandex.ru> 25.01.2018, 13:27, "Mathias Hasselmann" : > Let's see what people who know much more about compiler features than > any of us think about "#pragma once". Let's check what GCC and Clang do > for their C++ library headers: > >    $ grep -r pragma.*once /usr/include/clang/5.0.0/include > /usr/include/c++/7.2.0/ >    $ > > ...and this is about headers that target exactly one compiler and are > known to be locally installed. The latter statement is not exactly true, both libstdc++ and libc++ can be used by many compilers, and they also aren't guaranteed to be locally installed. > > Hope this helps, > Mathias > > Am 24.01.2018 um 13:19 schrieb Mitch Curtis: >>>  -----Original Message----- >>>  From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] >>>  Sent: Wednesday, 24 January 2018 1:11 PM >>>  To: Mitch Curtis >>>  Cc: Alexander Nassian ; development at qt- >>>  project.org >>>  Subject: Re: [Development] #pragma once >>> >>>  On 24 January 2018 at 12:34, Mitch Curtis wrote: >>>>>  -----Original Message----- >>>>>  From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] >>>>>  Sent: Wednesday, 24 January 2018 11:25 AM >>>>>  To: Alexander Nassian >>>>>  Cc: Mitch Curtis ; development at qt-project.org >>>>>  Subject: Re: [Development] #pragma once >>>>> >>>>>  On 24 January 2018 at 12:22, Alexander Nassian >>>>  dynamics.com> wrote: >>>>>>  Maybe because it’s not part of the C++ standard? >>>>> >>>>>  #pragma once is not a replacement for include guards. >>>> >>>>  Why not? >>>> >>>>>  It's not part of the C++ standard because it doesn't always work >>>> >>>>  In which ways? My quick search gave me these: >>>> >>>>  https://stackoverflow.com/a/1946730/904422 >>>>  https://en.wikipedia.org/wiki/Pragma_once#Caveats >>> >>>  That wikipedia link seems to describe the problems fairly accurately. >> >>  Do we have that issue in Qt? >> >>>>>  and modules are a superior solution anyway. >>>>  How so? >>> >>>  Because you can import the same module multiple times without concerns >>>  about re-definitions, and that import is much faster than parsing a header >>>  file. >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From ville.voutilainen at gmail.com Thu Jan 25 11:38:49 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 25 Jan 2018 12:38:49 +0200 Subject: [Development] #pragma once In-Reply-To: <2419731516876262@web32j.yandex.ru> References: <0c012dab-5358-ced3-6fa6-804c2377095f@taschenorakel.de> <2419731516876262@web32j.yandex.ru> Message-ID: On 25 January 2018 at 12:31, Konstantin Tokarev wrote: > > > 25.01.2018, 13:27, "Mathias Hasselmann" : >> Let's see what people who know much more about compiler features than >> any of us think about "#pragma once". Let's check what GCC and Clang do >> for their C++ library headers: >> >> $ grep -r pragma.*once /usr/include/clang/5.0.0/include >> /usr/include/c++/7.2.0/ >> $ >> >> ...and this is about headers that target exactly one compiler and are >> known to be locally installed. > > The latter statement is not exactly true, both libstdc++ and libc++ can be used > by many compilers, and they also aren't guaranteed to be locally installed. Correct. Both of those libraries make an effort to work with both gcc and clang, and to some extent EDG, and multiple versions thereof. However, that finding is interesting, but still anecdotal, and I doubt the suggestion of "people who know much more about compiler features than any of us" is entirely accurate in my case. :P From mitch.curtis at qt.io Thu Jan 25 11:53:54 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Thu, 25 Jan 2018 10:53:54 +0000 Subject: [Development] #pragma once In-Reply-To: <0c012dab-5358-ced3-6fa6-804c2377095f@taschenorakel.de> References: <0c012dab-5358-ced3-6fa6-804c2377095f@taschenorakel.de> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > project.org] On Behalf Of Mathias Hasselmann > Sent: Thursday, 25 January 2018 11:27 AM > To: development at qt-project.org > Subject: Re: [Development] #pragma once > > Let's see what people who know much more about compiler features than > any of us think about "#pragma once". Let's check what GCC and Clang do for > their C++ library headers: > > $ grep -r pragma.*once /usr/include/clang/5.0.0/include > /usr/include/c++/7.2.0/ > $ > > ...and this is about headers that target exactly one compiler and are known > to be locally installed. > > Hope this helps, > Mathias It kinda helps, although it doesn't say why they chose that. I'm here to learn why we're not using it, not to try to convince everyone that we should be using it. The reasons I've seen so far (build system stuff, etc.) are outside my experience, so I guess I'm just gonna have to be content with "just don't do it". :) > Am 24.01.2018 um 13:19 schrieb Mitch Curtis: > > > > > >> -----Original Message----- > >> From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] > >> Sent: Wednesday, 24 January 2018 1:11 PM > >> To: Mitch Curtis > >> Cc: Alexander Nassian ; > >> development at qt- project.org > >> Subject: Re: [Development] #pragma once > >> > >> On 24 January 2018 at 12:34, Mitch Curtis wrote: > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] > >>>> Sent: Wednesday, 24 January 2018 11:25 AM > >>>> To: Alexander Nassian > >>>> Cc: Mitch Curtis ; development at qt-project.org > >>>> Subject: Re: [Development] #pragma once > >>>> > >>>> On 24 January 2018 at 12:22, Alexander Nassian >>>> dynamics.com> wrote: > >>>>> Maybe because it’s not part of the C++ standard? > >>>> > >>>> #pragma once is not a replacement for include guards. > >>> > >>> Why not? > >>> > >>>> It's not part of the C++ standard because it doesn't always work > >>> > >>> In which ways? My quick search gave me these: > >>> > >>> https://stackoverflow.com/a/1946730/904422 > >>> https://en.wikipedia.org/wiki/Pragma_once#Caveats > >> > >> That wikipedia link seems to describe the problems fairly accurately. > > > > Do we have that issue in Qt? > > > >>>> and modules are a superior solution anyway. > >>> How so? > >> > >> Because you can import the same module multiple times without > >> concerns about re-definitions, and that import is much faster than > >> parsing a header file. > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Eike.Ziller at qt.io Thu Jan 25 12:24:35 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Thu, 25 Jan 2018 11:24:35 +0000 Subject: [Development] #pragma once In-Reply-To: References: <0c012dab-5358-ced3-6fa6-804c2377095f@taschenorakel.de> Message-ID: <4D682990-229F-42E4-A2FF-BECD86FB400D@qt.io> > On 25. Jan 2018, at 11:53, Mitch Curtis wrote: > >> -----Original Message----- >> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- >> project.org] On Behalf Of Mathias Hasselmann >> Sent: Thursday, 25 January 2018 11:27 AM >> To: development at qt-project.org >> Subject: Re: [Development] #pragma once >> >> Let's see what people who know much more about compiler features than >> any of us think about "#pragma once". Let's check what GCC and Clang do for >> their C++ library headers: >> >> $ grep -r pragma.*once /usr/include/clang/5.0.0/include >> /usr/include/c++/7.2.0/ >> $ >> >> ...and this is about headers that target exactly one compiler and are known >> to be locally installed. >> >> Hope this helps, >> Mathias > > It kinda helps, although it doesn't say why they chose that. I'm here to learn why we're not using it, not to try to convince everyone that we should be using it. The reasons I've seen so far (build system stuff, etc.) are outside my experience, so I guess I'm just gonna have to be content with "just don't do it". :) Both have their own sets of inadequacies it seems, so switching from one to the other mostly changes these sets, but users of Qt are at least used to the current set. In Qt Creator we control most users of the API, the set of used compilers is smaller, and in general the scope, so switching there was not much of a risk. The benefit in Qt Creator is also greater, because it makes refactoring easier, and that is something that we do a lot in Qt Creator code. > Am 24.01.2018 um 13:19 schrieb Mitch Curtis: >>> >>> >>>> -----Original Message----- >>>> From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] >>>> Sent: Wednesday, 24 January 2018 1:11 PM >>>> To: Mitch Curtis >>>> Cc: Alexander Nassian ; >>>> development at qt- project.org >>>> Subject: Re: [Development] #pragma once >>>> >>>> On 24 January 2018 at 12:34, Mitch Curtis wrote: >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] >>>>>> Sent: Wednesday, 24 January 2018 11:25 AM >>>>>> To: Alexander Nassian >>>>>> Cc: Mitch Curtis ; development at qt-project.org >>>>>> Subject: Re: [Development] #pragma once >>>>>> >>>>>> On 24 January 2018 at 12:22, Alexander Nassian >>>>> dynamics.com> wrote: >>>>>>> Maybe because it’s not part of the C++ standard? >>>>>> >>>>>> #pragma once is not a replacement for include guards. >>>>> >>>>> Why not? >>>>> >>>>>> It's not part of the C++ standard because it doesn't always work >>>>> >>>>> In which ways? My quick search gave me these: >>>>> >>>>> https://stackoverflow.com/a/1946730/904422 >>>>> https://en.wikipedia.org/wiki/Pragma_once#Caveats >>>> >>>> That wikipedia link seems to describe the problems fairly accurately. >>> >>> Do we have that issue in Qt? >>> >>>>>> and modules are a superior solution anyway. >>>>> How so? >>>> >>>> Because you can import the same module multiple times without >>>> concerns about re-definitions, and that import is much faster than >>>> parsing a header file. >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Morten.Sorvig at qt.io Thu Jan 25 13:31:27 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Thu, 25 Jan 2018 12:31:27 +0000 Subject: [Development] Using native webview on OS X In-Reply-To: <14241516716712@web18o.yandex.ru> References: <593911516636176@web39j.yandex.ru> <3ED7650A-6799-46F5-A972-6861F8EE9323@qt.io> <14241516716712@web18o.yandex.ru> Message-ID: <78030968-9419-48DF-B13F-A5FF35FA0125@qt.io> > On 23 Jan 2018, at 15:11, Konstantin Tokarev wrote: > > 23.01.2018, 17:09, "Morten Sørvig" : >> >> The QtWebEngine requirement does seem to run counter to the purpose of the QtWebView module. >> >> It’s not really clear from the history what happened, but I think we can restore the original behavior: >> >> https://codereview.qt-project.org/#/c/217706/ > > There was a discussion about run-time plugins in QtWebView, if they were implemented it won't be > a problem to load and use QtWebEngine backend if it is really needed, and avoid it otherwise > In the end we decided to go with this approach and finalize the plugin patch for dev. The other branches will be left as-is. In the mean time it's possible is to build QtWebView from source with the above patch if you want to avoid the QtWebEngine requirement. Morten From jani.heikkinen at qt.io Thu Jan 25 14:08:13 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 25 Jan 2018 13:08:13 +0000 Subject: [Development] New Qt snapshots available Message-ID: Hi, We have published online snapshots for Qt 5.10.1 and Qt 5.11 Alpha. You can find those from 'Preview' node in online installer br, Jani From denis.shienkov at gmail.com Thu Jan 25 16:50:02 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 25 Jan 2018 18:50:02 +0300 Subject: [Development] New Qt snapshots available In-Reply-To: References: Message-ID: <90f8038f-59e1-ea4b-e5a2-8c803573bae0@gmail.com> Hi, What about adding the snapshots of QtC 4.5.1 and 4.6.x to the MaintenanceTool? Because it is ugly to install some future QtC's snapshots separatelly. What if I want to upgrade QtC to next snapshot version? E.g. I do not want to have a more than one installed QtC instance, or, e.g. I want to uncheck/uninstall a default QtC. Is it possible to make this more flexible for MaintenanceTool? BR, Denis 25.01.2018 16:08, Jani Heikkinen пишет: > Hi, > > We have published online snapshots for Qt 5.10.1 and Qt 5.11 Alpha. You can find those from 'Preview' node in online installer > > br, > Jani > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From sschilz at pasco.com Thu Jan 25 21:05:47 2018 From: sschilz at pasco.com (Steve Schilz) Date: Thu, 25 Jan 2018 20:05:47 +0000 Subject: [Development] Using Native web view on OS X Message-ID: >>>>> 22.01.2018, 18:37, "Alberto Mardegan" : >>>>> Hi all! >>>>> ??I've developed a desktop application which uses the WebView QML >>>>> module, with the hope of publishing it in the Apple store. However, >>>>> unless I am seriously mistaken, this is just not possible (or maybe the >>>>> documentation needs some serious love). >>>>> >>>>> No matter what I try, it seems that QtWebEngine is always required! >>>>> >>>>> If I simply remove QtWebEngine from my Qt installation, building the >>>>> application succeeds but then when I run it I get the same error as in >>>>> https://bugreports.qt.io/browse/QTBUG-63107 >>>>> >>>>> If I look at src/webview/qtwebviewfunctions.cpp it looks like the >>>>> decision to use the native webview vs QtWebEngine is done at runtime, >>>>> but for some reason it looks like one still needs to have QtWebEngine >>>>> available in order for QtWebView to build successfully. With the obvious >>>>> consequence that one won't be able to publish one's app into the Apple >>>>> store. >>>>> >>>>> Is there some reason why the QtWebEngine support library isn't dlopen'ed >>>>> at runtime? Can I file a bug about that? >>>>> >>>>> From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable >>>>> is required to use native backend. >>>>> >>>>> [1] https://codereview.qt-project.org/#/c/162337/ >>>>> >>>>> >>>>> Ciao, >>>>? ?Alberto >>>> ?On 22/01/2018 18:49, Konstantin Tokarev wrote: >>>> ?From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable is required to use native backend. >>>> >>>> ?[1] https://codereview.qt-project.org/#/c/162337/ >>>> >>>> Regards, >>>> Konstantin >>> ?On 22 Jan 2018, at 18:22, Alberto Mardegan wrote: >>> ?Yes, but still QtWebEngine is required, as QtWebView is linking to it. >>> ?I've now removed a few lines of code here and there and got a version of >>> ?QtWebView which builds fine under macos without being linked to QtWebEngine. >> ?I'll soon try to see if it actually works. >>> >>> ?Ciao, >>> ??Alberto >>> >> >> 23.01.2018, 17:09, "Morten S?rvig" : >> The QtWebEngine requirement does seem to run counter to the purpose of the QtWebView module. >> >> It?s not really clear from the history what happened, but I think we can restore the original behavior: >> >> https://codereview.qt-project.org/#/c/217706/ >> >> There was a discussion about run-time plugins in QtWebView, if they were implemented it won't be >> a problem to load and use QtWebEngine backend if it is really needed, and avoid it otherwise >> >> >> Morten >> > 23.01.2018, 17:09, "Morten S?rvig" : > In the end we decided to go with this approach and finalize the plugin patch for dev. The other branches > will be left as-is. In the mean time it's possible is to build QtWebView from source with the above patch > If you want to avoid the QtWebEngine requirement. > > Morten > Apologies in advance if this comes off in any way as rude, I love Qt, and respect everyone here greatly. Am I correct in understanding that you are saying that prebuilt Qt packages cannot be used to submit to the app store, And that anyone who wishes to use Qt to develop an app on OSX and submit to the app store must be savvy enough to Build from source, and locate this thread in the dev newsgroup, and then apply the patch specified? Wasn't this thread started by someone that was frustrated after having gone through that exact process? We use QtWebEngine on Windows, and it works well, but do not use it on Mac or iOS because of the App Store requirements. (We are a commercial customer) I was frustrated by a similar decision with Qt Multimedia where the default backend on Windows was changed From AVFoundation (Which can play x264 encoded video out of the box) to DirectShow (which cannot). In both cases, this decision pushes users away from Qt because it does not 'just work' as expected, and also makes it necessary to compile Qt to get basic functionality working. (IMHO, it should not be necessary for most end users to compile Qt) Qt has gone to very great lengths with Qt Creator and the examples that 'just work' out of the box, which in my Opinion is fantastic! Although QtWebEngine is wonderful, it seems to me that given the App Store requirements that we must use the native WebView, that it might be wise, and benefit Qt as a whole to reconsider this decision. Steve Schilz Software Engineer III PASCO scientific www.pasco.com think science From rjvbertin at gmail.com Thu Jan 25 23:11:32 2018 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 25 Jan 2018 23:11:32 +0100 Subject: [Development] cocoa:fontengine=freetype and bitmap fonts Message-ID: <28176826.5eR88cPZfY@portia.local> Hi, One of the surprising side-effects of using the FreeType fontengine in general use is that I sometimes get a bitmap font, esp. in the Assistant. I'd noticed this on Linux too, btw. Turns out that this happens (only?) with the Helvetica font. I do have XQuartz installed (with the accompanying set of bitmap fonts) but I think this is rather a True/OpenType font with embedded bitmaps for certain smaller sizes, because the effect disappears when I scale the text up. Calling QFont::setStyleStrategy(QFont::ForceOutline) fixes the issue (PreferOutline is not enough, sadly). I'd love to make this a global default by adding it to a style or platform theme, but apparently there is no way to set a (change the) default style strategy? Thanks, R. From Eike.Ziller at qt.io Fri Jan 26 09:02:10 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Fri, 26 Jan 2018 08:02:10 +0000 Subject: [Development] New Qt snapshots available In-Reply-To: <90f8038f-59e1-ea4b-e5a2-8c803573bae0@gmail.com> References: <90f8038f-59e1-ea4b-e5a2-8c803573bae0@gmail.com> Message-ID: <73CB024B-39AA-49B9-AFB7-D0D7001D3309@qt.io> > On 25. Jan 2018, at 16:50, Denis Shienkov wrote: > > Hi, > > What about adding the snapshots of QtC 4.5.1 and 4.6.x to the MaintenanceTool? > > Because it is ugly to install some future QtC's snapshots separatelly. > What if I want to upgrade QtC to next snapshot version? > > E.g. I do not want to have a more than one installed QtC instance, > or, e.g. I want to uncheck/uninstall a default QtC. > > Is it possible to make this more flexible for MaintenanceTool? It got more flexible recently (we released the 4.5 beta & rc through the online installer), and we are working on making it more flexible (like making Qt Creator optional). We currently do not have concrete plans for providing Qt Creator _snapshots_, though I’d love to provide something. I’m not sure if providing daily automated snapshots is feasible though, since we do not want to break online installations (this is not about providing a broken Qt Creator, it is more about breaking the user’s installation in the whole when we adapt something there). Br, Eike > BR, > Denis > > 25.01.2018 16:08, Jani Heikkinen пишет: >> Hi, >> >> We have published online snapshots for Qt 5.10.1 and Qt 5.11 Alpha. You can find those from 'Preview' node in online installer >> >> br, >> Jani >> >> >> _______________________________________________ >> Development mailing list >> >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Kai.Koehne at qt.io Fri Jan 26 09:34:36 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 26 Jan 2018 08:34:36 +0000 Subject: [Development] Using Native web view on OS X In-Reply-To: References: Message-ID: > Am I correct in understanding that you are saying that prebuilt Qt packages cannot be used to submit to the app store, > And that anyone who wishes to use Qt to develop an app on OSX and submit to the app store must be savvy enough to > Build from source, and locate this thread in the dev newsgroup, and then apply the patch specified? Let's keep in mind that this is about apps using Qt WebView and Qt WebEngine, not about the rest of Qt. > Wasn't this thread started by someone that was frustrated after having gone through that exact process? > > We use QtWebEngine on Windows, and it works well, but do not use it on Mac or iOS because of the App Store requirements. (We are a commercial customer) We tried to make Qt WebEngine on macOS to be compliant with the Mac App Store for some time. In Qt 5.9 there's a configure switch for it: -appstore-compliant. Anyhow, unfortunately we found out that this is not feasible anymore with newer Chromium versions, so we had to drop that for Qt 5.10 and future versions. But even in Qt 5.9 it was a (compile time) opt-in, because you effectively loose functionality which might not be what you want. > I was frustrated by a similar decision with Qt Multimedia where the default backend on Windows was changed From > AVFoundation (Which can play x264 encoded video out of the box) to DirectShow (which cannot). > > In both cases, this decision pushes users away from Qt because it does not 'just work' as expected, and also > makes it necessary to compile Qt to get basic functionality working. > (IMHO, it should not be necessary for most end users to compile Qt) This is indeed a goal. But this is about tradeoffs: Unfortunately we don't have 'the perfect' backend that covers all use cases for Qt WebView on macOS right now. > Qt has gone to very great lengths with Qt Creator and the examples that 'just work' out of the box, which in my Opinion is fantastic! > Although QtWebEngine is wonderful, it seems to me that given the App Store requirements that we must use the native WebView, that it might be wise, and > benefit Qt as a whole to reconsider this decision. Indeed, and we agreed to solve this properly by introducing a plugin based architecture: https://codereview.qt-project.org/#/c/207651/ It's just not something you want to do in a patch level release, because stability. Regards Kai ________________________________ From: Development on behalf of Steve Schilz Sent: Thursday, January 25, 2018 9:05:47 PM To: development at qt-project.org Subject: Re: [Development] Using Native web view on OS X >>>>> 22.01.2018, 18:37, "Alberto Mardegan" : >>>>> Hi all! >>>>> ??I've developed a desktop application which uses the WebView QML >>>>> module, with the hope of publishing it in the Apple store. However, >>>>> unless I am seriously mistaken, this is just not possible (or maybe the >>>>> documentation needs some serious love). >>>>> >>>>> No matter what I try, it seems that QtWebEngine is always required! >>>>> >>>>> If I simply remove QtWebEngine from my Qt installation, building the >>>>> application succeeds but then when I run it I get the same error as in >>>>> https://bugreports.qt.io/browse/QTBUG-63107 A QML application that is using Webview will crash on ... bugreports.qt.io No reviews matched the request. Check your Options in the drop-down menu of this sections header. >>>>> >>>>> If I look at src/webview/qtwebviewfunctions.cpp it looks like the >>>>> decision to use the native webview vs QtWebEngine is done at runtime, >>>>> but for some reason it looks like one still needs to have QtWebEngine >>>>> available in order for QtWebView to build successfully. With the obvious >>>>> consequence that one won't be able to publish one's app into the Apple >>>>> store. >>>>> >>>>> Is there some reason why the QtWebEngine support library isn't dlopen'ed >>>>> at runtime? Can I file a bug about that? >>>>> >>>>> From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable >>>>> is required to use native backend. >>>>> >>>>> [1] https://codereview.qt-project.org/#/c/162337/ Qt - Gerrit Code Review codereview.qt-project.org Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet Qt; Qt Repository Browser >>>>> >>>>> >>>>> Ciao, >>>>? ?Alberto >>>> ?On 22/01/2018 18:49, Konstantin Tokarev wrote: >>>> ?From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable is required to use native backend. >>>> >>>> ?[1] https://codereview.qt-project.org/#/c/162337/ Qt - Gerrit Code Review codereview.qt-project.org Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet Qt; Qt Repository Browser >>>> >>>> Regards, >>>> Konstantin >>> ?On 22 Jan 2018, at 18:22, Alberto Mardegan wrote: >>> ?Yes, but still QtWebEngine is required, as QtWebView is linking to it. >>> ?I've now removed a few lines of code here and there and got a version of >>> ?QtWebView which builds fine under macos without being linked to QtWebEngine. >> ?I'll soon try to see if it actually works. >>> >>> ?Ciao, >>> ??Alberto >>> >> >> 23.01.2018, 17:09, "Morten S?rvig" : >> The QtWebEngine requirement does seem to run counter to the purpose of the QtWebView module. >> >> It?s not really clear from the history what happened, but I think we can restore the original behavior: >> >> https://codereview.qt-project.org/#/c/217706/ Qt - Gerrit Code Review codereview.qt-project.org Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet Qt; Qt Repository Browser >> >> There was a discussion about run-time plugins in QtWebView, if they were implemented it won't be >> a problem to load and use QtWebEngine backend if it is really needed, and avoid it otherwise >> >> >> Morten >> > 23.01.2018, 17:09, "Morten S?rvig" : > In the end we decided to go with this approach and finalize the plugin patch for dev. The other branches > will be left as-is. In the mean time it's possible is to build QtWebView from source with the above patch > If you want to avoid the QtWebEngine requirement. > > Morten > Apologies in advance if this comes off in any way as rude, I love Qt, and respect everyone here greatly. Am I correct in understanding that you are saying that prebuilt Qt packages cannot be used to submit to the app store, And that anyone who wishes to use Qt to develop an app on OSX and submit to the app store must be savvy enough to Build from source, and locate this thread in the dev newsgroup, and then apply the patch specified? Wasn't this thread started by someone that was frustrated after having gone through that exact process? We use QtWebEngine on Windows, and it works well, but do not use it on Mac or iOS because of the App Store requirements. (We are a commercial customer) I was frustrated by a similar decision with Qt Multimedia where the default backend on Windows was changed From AVFoundation (Which can play x264 encoded video out of the box) to DirectShow (which cannot). In both cases, this decision pushes users away from Qt because it does not 'just work' as expected, and also makes it necessary to compile Qt to get basic functionality working. (IMHO, it should not be necessary for most end users to compile Qt) Qt has gone to very great lengths with Qt Creator and the examples that 'just work' out of the box, which in my Opinion is fantastic! Although QtWebEngine is wonderful, it seems to me that given the App Store requirements that we must use the native WebView, that it might be wise, and benefit Qt as a whole to reconsider this decision. Steve Schilz Software Engineer III PASCO scientific www.pasco.com think science _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Fri Jan 26 10:18:03 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 26 Jan 2018 12:18:03 +0300 Subject: [Development] New Qt snapshots available In-Reply-To: <73CB024B-39AA-49B9-AFB7-D0D7001D3309@qt.io> References: <90f8038f-59e1-ea4b-e5a2-8c803573bae0@gmail.com> <73CB024B-39AA-49B9-AFB7-D0D7001D3309@qt.io> Message-ID: Ok, thanks. 2018-01-26 11:02 GMT+03:00 Eike Ziller : > > > > On 25. Jan 2018, at 16:50, Denis Shienkov > wrote: > > > > Hi, > > > > What about adding the snapshots of QtC 4.5.1 and 4.6.x to the > MaintenanceTool? > > > > Because it is ugly to install some future QtC's snapshots separatelly. > > What if I want to upgrade QtC to next snapshot version? > > > > E.g. I do not want to have a more than one installed QtC instance, > > or, e.g. I want to uncheck/uninstall a default QtC. > > > > Is it possible to make this more flexible for MaintenanceTool? > > It got more flexible recently (we released the 4.5 beta & rc through the > online installer), and we are working on making it more flexible (like > making Qt Creator optional). > We currently do not have concrete plans for providing Qt Creator > _snapshots_, though I’d love to provide something. I’m not sure if > providing daily automated snapshots is feasible though, since we do not > want to break online installations (this is not about providing a broken Qt > Creator, it is more about breaking the user’s installation in the whole > when we adapt something there). > > Br, Eike > > > BR, > > Denis > > > > 25.01.2018 16:08, Jani Heikkinen пишет: > >> Hi, > >> > >> We have published online snapshots for Qt 5.10.1 and Qt 5.11 Alpha. You > can find those from 'Preview' node in online installer > >> > >> br, > >> Jani > >> > >> > >> _______________________________________________ > >> Development mailing list > >> > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > eike.ziller at qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at qt.io Fri Jan 26 10:30:58 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Fri, 26 Jan 2018 09:30:58 +0000 Subject: [Development] Using Native web view on OS X In-Reply-To: References: Message-ID: <46876DEE-B3C0-4AD4-8677-386748598DC5@qt.io> > On 25 Jan 2018, at 21:05, Steve Schilz wrote: > >>>>>> 22.01.2018, 18:37, "Alberto Mardegan" : >>>>>> Hi all! >>>>>> ??I've developed a desktop application which uses the WebView QML >>>>>> module, with the hope of publishing it in the Apple store. However, >>>>>> unless I am seriously mistaken, this is just not possible (or maybe the >>>>>> documentation needs some serious love). >>>>>> >>>>>> No matter what I try, it seems that QtWebEngine is always required! >>>>>> >>>>>> If I simply remove QtWebEngine from my Qt installation, building the >>>>>> application succeeds but then when I run it I get the same error as in >>>>>> https://bugreports.qt.io/browse/QTBUG-63107 >>>>>> >>>>>> If I look at src/webview/qtwebviewfunctions.cpp it looks like the >>>>>> decision to use the native webview vs QtWebEngine is done at runtime, >>>>>> but for some reason it looks like one still needs to have QtWebEngine >>>>>> available in order for QtWebView to build successfully. With the obvious >>>>>> consequence that one won't be able to publish one's app into the Apple >>>>>> store. >>>>>> >>>>>> Is there some reason why the QtWebEngine support library isn't dlopen'ed >>>>>> at runtime? Can I file a bug about that? >>>>>> >>>>>> From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable >>>>>> is required to use native backend. >>>>>> >>>>>> [1] https://codereview.qt-project.org/#/c/162337/ >>>>>> >>>>>> >>>>>> Ciao, >>>>> ? ?Alberto > >>>>> ?On 22/01/2018 18:49, Konstantin Tokarev wrote: >>>>> ?From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable is required to use native backend. >>>>> >>>>> ?[1] https://codereview.qt-project.org/#/c/162337/ >>>>> >>>>> Regards, >>>>> Konstantin > >>>> ?On 22 Jan 2018, at 18:22, Alberto Mardegan wrote: >>>> ?Yes, but still QtWebEngine is required, as QtWebView is linking to it. >>>> ?I've now removed a few lines of code here and there and got a version of >>>> ?QtWebView which builds fine under macos without being linked to QtWebEngine. >>> ?I'll soon try to see if it actually works. >>>> >>>> ?Ciao, >>>> ??Alberto >>>> > >>> >> 23.01.2018, 17:09, "Morten S?rvig" : >>> The QtWebEngine requirement does seem to run counter to the purpose of the QtWebView module. >>> >>> It?s not really clear from the history what happened, but I think we can restore the original behavior: >>> >>> https://codereview.qt-project.org/#/c/217706/ >>> >>> There was a discussion about run-time plugins in QtWebView, if they were implemented it won't be >>> a problem to load and use QtWebEngine backend if it is really needed, and avoid it otherwise >>> >>> >>> Morten >>> > >> 23.01.2018, 17:09, "Morten S?rvig" : >> In the end we decided to go with this approach and finalize the plugin patch for dev. The other branches >> will be left as-is. In the mean time it's possible is to build QtWebView from source with the above patch >> If you want to avoid the QtWebEngine requirement. >> >> Morten >> > Apologies in advance if this comes off in any way as rude, I love Qt, and respect everyone here greatly. > > Am I correct in understanding that you are saying that prebuilt Qt packages cannot be used to submit to the app store, > And that anyone who wishes to use Qt to develop an app on OSX and submit to the app store must be savvy enough to > Build from source, and locate this thread in the dev newsgroup, and then apply the patch specified? I agree with this point, but as I said we concluded with not changing the current Qt versions. Order will be restored once the plugin patch is released. I’m not sure what the default plugin will be yet, but at the very least you can select the native plugin by not building QWebEngine or not deploying the QWebEngine plugin (e.g. with macdeployqt -appstore-compliant). Morten From igor.mironchik at gmail.com Fri Jan 26 16:14:09 2018 From: igor.mironchik at gmail.com (Igor Mironchik) Date: Fri, 26 Jan 2018 18:14:09 +0300 Subject: [Development] Rebasing Message-ID: Hi, What if you have a patch based on 5.11 branch and you want to rebase it to 5.9, how do you do such work? Do you use regular git rebase? Or maybe you just do a new branch based on 5.9, do changes, commit and changes Change-Id to the existing and do push? Thank you. From annulen at yandex.ru Fri Jan 26 16:17:24 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 26 Jan 2018 18:17:24 +0300 Subject: [Development] Rebasing In-Reply-To: References: Message-ID: <923211516979844@web54o.yandex.ru> 26.01.2018, 18:14, "Igor Mironchik" : > Hi, > > What if you have a patch based on 5.11 branch and you want to rebase it > to 5.9, how do you do such work? Do you use regular git rebase? Or maybe > you just do a new branch based on 5.9, do changes, commit and changes > Change-Id to the existing and do push? Checkout 5.9, cherry-pick your old patch > > Thank you. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From cavendish.qi at gmail.com Fri Jan 26 16:21:55 2018 From: cavendish.qi at gmail.com (Liang Qi) Date: Fri, 26 Jan 2018 16:21:55 +0100 Subject: [Development] Rebasing In-Reply-To: References: Message-ID: https://wiki.qt.io/Branch_Guidelines search "cherry-pick" BTW, you always can ask in #qt-labs channel at freenode, see https://wiki.qt.io/Online_Communities . Perhaps will get reply much faster without sending emails in mailing list. --Liang On 26 January 2018 at 16:14, Igor Mironchik wrote: > Hi, > > What if you have a patch based on 5.11 branch and you want to rebase it to > 5.9, how do you do such work? Do you use regular git rebase? Or maybe you > just do a new branch based on 5.9, do changes, commit and changes Change-Id > to the existing and do push? > > Thank you. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Jan 26 17:31:59 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Jan 2018 08:31:59 -0800 Subject: [Development] Rebasing In-Reply-To: <923211516979844@web54o.yandex.ru> References: <923211516979844@web54o.yandex.ru> Message-ID: <3329363.3CIq0LJ5by@tjmaciei-mobl1> On sexta-feira, 26 de janeiro de 2018 07:17:24 PST Konstantin Tokarev wrote: > 26.01.2018, 18:14, "Igor Mironchik" : > > Hi, > > > > What if you have a patch based on 5.11 branch and you want to rebase it > > to 5.9, how do you do such work? Do you use regular git rebase? Or maybe > > you just do a new branch based on 5.9, do changes, commit and changes > > Change-Id to the existing and do push? > > Checkout 5.9, cherry-pick your old patch Which is effectively equal to: git rebase --onto origin/5.9 origin/5.11 my-patch-branch -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sschilz at pasco.com Fri Jan 26 17:57:59 2018 From: sschilz at pasco.com (Steve Schilz) Date: Fri, 26 Jan 2018 16:57:59 +0000 Subject: [Development] Development Digest, Vol 76, Issue 53 In-Reply-To: References: Message-ID: <76E0B9C6-C9E9-4759-90DE-CBD9A40E17D5@pasco.com> On 1/26/18, 7:22 AM, "Development on behalf of development-request at qt-project.org" wrote: >On 25 Jan 2018, at 21:05, Steve Schilz wrote: >>>>>>22.01.2018, 18:37, "Alberto Mardegan" : >>>>>> Hi all! >>>>>> ??I've developed a desktop application which uses the WebView QML >>>>>> module, with the hope of publishing it in the Apple store. However, >>>>>> unless I am seriously mistaken, this is just not possible (or maybe the >>>>>> documentation needs some serious love). >>>>>> No matter what I try, it seems that QtWebEngine is always required! >>>>>> If I simply remove QtWebEngine from my Qt installation, building the >>>>>> application succeeds but then when I run it I get the same error as in >>>>>> https://bugreports.qt.io/browse/QTBUG-63107 >>>>>> If I look at src/webview/qtwebviewfunctions.cpp it looks like the >>>>>> decision to use the native webview vs QtWebEngine is done at runtime, >>>>>> but for some reason it looks like one still needs to have QtWebEngine >>>>>> available in order for QtWebView to build successfully. With the obvious >>>>>> consequence that one won't be able to publish one's app into the Apple >>>>>> store. >>>>>> Is there some reason why the QtWebEngine support library isn't dlopen'ed >>>>>> at runtime? Can I file a bug about that? >>>>>> From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable >>>>>> is required to use native backend. >>>>>> [1] https://codereview.qt-project.org/#/c/162337/ >>>>>>Ciao, >>>>>? ?Alberto >>>>> ?On 22/01/2018 18:49, Konstantin Tokarev wrote: >>>>> ?From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable is required to use native backend. >>>>> >>>>> ?[1] https://codereview.qt-project.org/#/c/162337/ >>>>> Regards, >>>>> Konstantin >>>> ?On 22 Jan 2018, at 18:22, Alberto Mardegan wrote: >>>> ?Yes, but still QtWebEngine is required, as QtWebView is linking to it. >>>> ?I've now removed a few lines of code here and there and got a version of >>>> ?QtWebView which builds fine under macos without being linked to QtWebEngine. >>> ?I'll soon try to see if it actually works. >>>> ?Ciao, >>>> ??Alberto >>> >> 23.01.2018, 17:09, "Morten S?rvig" : >>> The QtWebEngine requirement does seem to run counter to the purpose of the QtWebView module. >>> It?s not really clear from the history what happened, but I think we can restore the original behavior: >>> https://codereview.qt-project.org/#/c/217706/ >>> There was a discussion about run-time plugins in QtWebView, if they were implemented it won't be >>> a problem to load and use QtWebEngine backend if it is really needed, and avoid it otherwise >>> Morten >> 23.01.2018, 17:09, "Morten S?rvig" : >> In the end we decided to go with this approach and finalize the plugin patch for dev. The other branches >> will be left as-is. In the mean time it's possible is to build QtWebView from source with the above patch >> If you want to avoid the QtWebEngine requirement. >> >> Morten >>Apologies in advance if this comes off in any way as rude, I love Qt, and respect everyone here greatly. >>Am I correct in understanding that you are saying that prebuilt Qt packages cannot be used to submit to the app store, >>And that anyone who wishes to use Qt to develop an app on OSX and submit to the app store must be savvy enough to >>Build from source, and locate this thread in the dev newsgroup, and then apply the patch specified? > > I agree with this point, but as I said we concluded with not changing the current Qt versions. Order > will be restored once the plugin patch is released. I?m not sure what the default plugin will be yet, but at > the very least you can select the native plugin by not building QWebEngine or not deploying the QWebEngine > plugin (e.g. with macdeployqt -appstore-compliant). > > Morten > Thanks for the additional clarifications from Morten and Kai. It wasn't clear to me from the above discussion at 23.01.2018, 17:09 that there are definite plans to go forward with the plugin. We have been using Qt for 8 years now, since the 4.x timeframe, and from that vantage point we definitely understand that things don't happen immediately, but that they do happen in as timely a fashion as is possible while maintaining the high standards that Qt is known for. Steve Schilz Pasco Scientific Think Science From tony.sarajarvi at qt.io Fri Jan 26 21:34:49 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Fri, 26 Jan 2018 20:34:49 +0000 Subject: [Development] CI updates ongoing Message-ID: Hi Our CI hosts run on Ubuntu, but sadly not on the latest version. We have 16.04 and 16.10 releases in use which need to be updated quickly. As we transition over, we will move hosts gradually to a new version of the CI running on 17.10. So during the next few days the CI will be a bit slower with reduced capacity. With regards, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangelog at gmail.com Sat Jan 27 00:12:58 2018 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Sat, 27 Jan 2018 00:12:58 +0100 Subject: [Development] CI updates ongoing In-Reply-To: References: Message-ID: On 26 January 2018 at 21:34, Tony Sarajärvi wrote: > Hi > > > > Our CI hosts run on Ubuntu, but sadly not on the latest version. We have > 16.04 and 16.10 releases in use which need to be updated quickly. > > As we transition over, we will move hosts gradually to a new version of the > CI running on 17.10. So during the next few days the CI will be a bit slower > with reduced capacity. Do you mean there won't be any CI node testing Ubuntu LTS? (Ok, 18.04 is due in a few months, but 18.04.1 is anyhow the recommended one for LTS users, so we're talking ~6 months from now). Thanks, -- Giuseppe D'Angelo From tony.sarajarvi at qt.io Sat Jan 27 07:39:15 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Sat, 27 Jan 2018 06:39:15 +0000 Subject: [Development] CI updates ongoing In-Reply-To: References: , Message-ID: Ah, sorry for the confusion. I'm not touching the distros we test on. That is the virtual machines, the configurations in qt5.git. I'm updating the host OS's that run the virtual machines. The thing that previously used to be ESXi from VMware before we switched to using Ubuntu/KVM with openNebula. The exception being the virtual machine running openNebula itself. That will also be updated. But as said. The updates will occur now as ubuntu moved their distros to their archives. Our deployment scripts don't work right of the bat anymore. We could modify them, but as we want to upgrade anyway at some point, we might as well do it now. -Tony Sent from my BlackBerry - the most secure mobile device From: dangelog at gmail.com Sent: January 27, 2018 01:13 To: tony.sarajarvi at qt.io Cc: development at qt-project.org Subject: Re: [Development] CI updates ongoing On 26 January 2018 at 21:34, Tony Sarajärvi wrote: > Hi > > > > Our CI hosts run on Ubuntu, but sadly not on the latest version. We have > 16.04 and 16.10 releases in use which need to be updated quickly. > > As we transition over, we will move hosts gradually to a new version of the > CI running on 17.10. So during the next few days the CI will be a bit slower > with reduced capacity. Do you mean there won't be any CI node testing Ubuntu LTS? (Ok, 18.04 is due in a few months, but 18.04.1 is anyhow the recommended one for LTS users, so we're talking ~6 months from now). Thanks, -- Giuseppe D'Angelo -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Sun Jan 28 10:57:18 2018 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 28 Jan 2018 10:57:18 +0100 Subject: [Development] Using Native web view on OS X References: Message-ID: <1775454.jL2Q5C5QZe@patux.local> Kai Koehne wrote: > Indeed, and we agreed to solve this properly by introducing a plugin based > architecture: https://codereview.qt-project.org/#/c/207651/ This wouldn't also be of interest for developers who want to target Apple's App Store. Assuming QtWebView is an appropriate choice for implementing a rich-text viewer for (mostly) local documents in any case. QtWebEngine is usually severely overkill for that purpose, QTextBrowser usually (just) not good enough. > > > It's just not something you want to do in a patch level release, because > stability. I'm thinking that stability shouldn't depend on whether you introduce this in a patchlevel release or a major release. (Or maybe I have a certain experience that "older" patch level releases are more stable? :) ) From jani.heikkinen at qt.io Mon Jan 29 06:54:26 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 29 Jan 2018 05:54:26 +0000 Subject: [Development] Branching from '5.10' to '5.10.1' started Message-ID: Hi all, We have soft branched '5.10.1' from '5.10' on Friday. Target is to do final downmerge from '5.10' -> '5.10.1' Friday 2.2.2018. Please finalize ongoing changes in '5.10' and start using '5.10.1' for new changes. First Qt 5.10.1 snapshot is already under testing and we are targeting to get Qt 5.10.1 out as soon as possible after final downmerge. So please minimize changes for Qt 5.10.1 from now on to get it out quickly! br, Jani From jani.heikkinen at qt.io Mon Jan 29 07:59:06 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 29 Jan 2018 06:59:06 +0000 Subject: [Development] Qt branches & proposal how to continue with those Message-ID: Hi, We have currently really many branches open: - 5.6 - 5.9 - 5.10 - 5.10.1 - 5.11 - dev In my opinion this is too much to handle effectively, especially because there is many branches in stable mode (see http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is in 'strict' mode and '5.9', 5.10' & '5.11' are in stable... I think we need to change that to be able to work efficiently & get releases out. So I am proposing following changes starting from 1st Feb 2018: - '5.6' will move in 'very strict' mode - '5.9' will move in 'strict' mode. So no direct submissions anymore, just cherry picks from stable - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too long) - '5.11' will be to one and only stable branch br, Jani From ville.voutilainen at gmail.com Mon Jan 29 08:49:44 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Mon, 29 Jan 2018 09:49:44 +0200 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: On 29 January 2018 at 08:59, Jani Heikkinen wrote: > - '5.6' will move in 'very strict' mode > - '5.9' will move in 'strict' mode. So no direct submissions anymore, just cherry picks from stable > - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too long) > - '5.11' will be to one and only stable branch The problem here is that there are bugfixes that need to go into 5.9 but cannot go into 5.11, for a variety of reasons. We need to keep 5.9 open for direct submissions. From jani.heikkinen at qt.io Mon Jan 29 09:06:41 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 29 Jan 2018 08:06:41 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: > -----Original Message----- > From: Ville Voutilainen [mailto:ville.voutilainen at gmail.com] > Sent: maanantai 29. tammikuuta 2018 9.50 > To: Jani Heikkinen > Cc: development at qt-project.org > Subject: Re: [Development] Qt branches & proposal how to continue with those > > On 29 January 2018 at 08:59, Jani Heikkinen wrote: > > - '5.6' will move in 'very strict' mode > > - '5.9' will move in 'strict' mode. So no direct submissions anymore, > > just cherry picks from stable > > - '5.10' will be closed and Qt 5.10.1 will be the final release from > > Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt > > 5.10 active too long) > > - '5.11' will be to one and only stable branch > > > The problem here is that there are bugfixes that need to go into 5.9 but cannot > go into 5.11, for a variety of reasons. We need to keep 5.9 open for direct > submissions. Hmm, I think putting '5.9' in cherry pick mode with this schedule is agreed way of working, see http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst And I don't see big issue there; amount of 5.9 specific fixes should be really minimal and if one really needed we can get that in without putting it first in stable: Cherry pick "mode" is more "way of working" & checks are included in sanity bot. And it can be overwritten if really needed. br, Jani From ville.voutilainen at gmail.com Mon Jan 29 09:14:30 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Mon, 29 Jan 2018 10:14:30 +0200 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: On 29 January 2018 at 10:06, Jani Heikkinen wrote: >> On 29 January 2018 at 08:59, Jani Heikkinen wrote: >> > - '5.6' will move in 'very strict' mode >> > - '5.9' will move in 'strict' mode. So no direct submissions anymore, >> > just cherry picks from stable >> > - '5.10' will be closed and Qt 5.10.1 will be the final release from >> > Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt >> > 5.10 active too long) >> > - '5.11' will be to one and only stable branch >> >> >> The problem here is that there are bugfixes that need to go into 5.9 but cannot >> go into 5.11, for a variety of reasons. We need to keep 5.9 open for direct >> submissions. > > Hmm, I think putting '5.9' in cherry pick mode with this schedule is agreed way of working, see http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst > And I don't see big issue there; amount of 5.9 specific fixes should be really minimal and if one really needed we can get that in without putting it first in stable: Cherry pick "mode" is more "way of working" & checks are included in sanity bot. And it can be overwritten if really needed. Yeah, and I was actually thinking more along the lines of boot2qt, where some things have completely different implementations between 5.9 and 5.11, and changes just don't merge. So alrighty then, consider my concern withdrawn. From Simon.Hausmann at qt.io Mon Jan 29 09:15:51 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 29 Jan 2018 08:15:51 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: Hi, I feel that we are generally guiding our users towards the LTS releases. The minor releases appear to address in particular users who need a particular feature before it hits the next LTS release. In the light of that, I think it would be better to keep the LTS branches open longer and stop doing patch releases for minor releases that are not LTS. Simon ________________________________ From: Development on behalf of Jani Heikkinen Sent: Monday, January 29, 2018 7:59:06 AM To: development at qt-project.org Subject: [Development] Qt branches & proposal how to continue with those Hi, We have currently really many branches open: - 5.6 - 5.9 - 5.10 - 5.10.1 - 5.11 - dev In my opinion this is too much to handle effectively, especially because there is many branches in stable mode (see http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is in 'strict' mode and '5.9', 5.10' & '5.11' are in stable... I think we need to change that to be able to work efficiently & get releases out. So I am proposing following changes starting from 1st Feb 2018: - '5.6' will move in 'very strict' mode - '5.9' will move in 'strict' mode. So no direct submissions anymore, just cherry picks from stable - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too long) - '5.11' will be to one and only stable branch br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Mon Jan 29 10:00:54 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Mon, 29 Jan 2018 09:00:54 +0000 (UTC) Subject: [Development] Qt branches & proposal how to continue with those References: Message-ID: On Mon, 29 Jan 2018 06:59:06 +0000, Jani Heikkinen wrote: > - '5.6' will move in 'very strict' mode - '5.9' will move in 'strict' > mode. This type of discussion has to be lead, before making a LTS promise ! Trying to change this later - without having any argument beside, that maintaining stable branches is cumbersome - makes your LTS promises nothing but unreliable. But IMHO you are also asking the wrong audience. Qt development is the right group, when discussing if a release should be a LTS one. But if you want to change the cycle of an existing LTS version you should ask those to whom you made the promise: the users. Speaking for myself: I'm only interested in LTS versions and I could easily live without releases that never go beyond 5.x.1 ( like f.e 5.10 ). Uwe From lars.knoll at qt.io Mon Jan 29 10:26:32 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 29 Jan 2018 09:26:32 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: > On 29 Jan 2018, at 10:00, Uwe Rathmann wrote: > > On Mon, 29 Jan 2018 06:59:06 +0000, Jani Heikkinen wrote: > >> - '5.6' will move in 'very strict' mode - '5.9' will move in 'strict' >> mode. > > This type of discussion has to be lead, before making a LTS promise ! Of course. We had that discussion, see QUIP 5. According to what's defined there, 5.6 should move into 'very strict' mode for the third year, so that is pretty much from now onwards. 5.9 should move into strict mode with cherry-picking, also in line with QUIP 5. So I agree with these two changes, they are IMO fully in line with what we have said and promised. I think this only leaves a question around the proposal for 5.10. We've usually left that branch open until the next minor release is out. Cheers, Lars > > Trying to change this later - without having any argument beside, that > maintaining stable branches is cumbersome - makes your LTS promises > nothing but unreliable. > > But IMHO you are also asking the wrong audience. Qt development is the > right group, when discussing if a release should be a LTS one. But if you > want to change the cycle of an existing LTS version you should ask those > to whom you made the promise: the users. > > Speaking for myself: I'm only interested in LTS versions and I could > easily live without releases that never go beyond 5.x.1 ( like f.e 5.10 ). > > Uwe > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From giuseppe.dangelo at kdab.com Mon Jan 29 10:31:14 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 29 Jan 2018 10:31:14 +0100 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: <8f399bb9-a01e-7fd2-4f36-38e08bcebfff@kdab.com> On 29/01/18 07:59, Jani Heikkinen wrote: > We have currently really many branches open: > - 5.6 > - 5.9 > - 5.10 > - 5.10.1 > - 5.11 > - dev > > In my opinion this is too much to handle effectively, especially because there is many branches in stable mode (see http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is in 'strict' mode and '5.9', 5.10' & '5.11' are in stable... I think we need to change that to be able to work efficiently & get releases out. Could you please elaborate, what's the problem at the moment when you say that it's "too much" to handle? Is it a matter that branches have become different enough that merges don't apply any longer? Is it a matter of bandwidth for the releasing team having to produce releases from several branches? > > So I am proposing following changes starting from 1st Feb 2018: > > - '5.6' will move in 'very strict' mode Which by the way is already the case, in practice. E.g. there have been ~20-30 patches landing in qtbase/5.6, with over half being fixes for flaky autotests. > - '5.9' will move in 'strict' mode. So no direct submissions anymore, just cherry picks from stable This was also proposed a few days ago (to change in 'strict' mode after 5.11 branching is completed). I have mixed feelings about that, in the sense that in 6 months from now noone will be doing the cherry-picks because of the extra work, thus leaving bugs in 5.9 in the name of stability, but somehow breaks the LTS promise. > - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too long) I don't agree, 5.10 releases should be done on a regular basis until 5.11.1 is out (Yes, .1, many users don't upgrade to .0 versions...) My 2 cents, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From jani.heikkinen at qt.io Mon Jan 29 11:10:22 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 29 Jan 2018 10:10:22 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <8f399bb9-a01e-7fd2-4f36-38e08bcebfff@kdab.com> References: <8f399bb9-a01e-7fd2-4f36-38e08bcebfff@kdab.com> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Giuseppe D'Angelo > Sent: maanantai 29. tammikuuta 2018 11.31 > To: development at qt-project.org > Subject: Re: [Development] Qt branches & proposal how to continue with those > > On 29/01/18 07:59, Jani Heikkinen wrote: > > We have currently really many branches open: > > - 5.6 > > - 5.9 > > - 5.10 > > - 5.10.1 > > - 5.11 > > - dev > > > > In my opinion this is too much to handle effectively, especially because there is > many branches in stable mode (see > http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is in > 'strict' mode and '5.9', 5.10' & '5.11' are in stable... I think we need to change > that to be able to work efficiently & get releases out. > > Could you please elaborate, what's the problem at the moment when you say > that it's "too much" to handle? Is it a matter that branches have become > different enough that merges don't apply any longer? Is it a matter of bandwidth > for the releasing team having to produce releases from several branches? The problem is resource usage side at the moment. I think merges are still applying quite well but it is really big effort needed to do merges from ('5.9.x')->'5.9' ->(5.10.x)->'5.10'->'5.11'->'dev'. This is manpower, hw capasity and timing issue: It takes really long time to get a fix in every branch where it is needed and it also consumes lots of hw capasity to run CI on all these branches + run qt5.git integrations. And of course it is really hard for release team to get that much releases out (also HW usage point of view: RTA uses quite much resources while testing all these releases and snapshots). Moving '5.9' to strict mode helps there with merges and removing one release would help with all these issues, that's why I did this proposal. br, Jani From adam.treat at qt.io Mon Jan 29 13:10:02 2018 From: adam.treat at qt.io (Adam Treat) Date: Mon, 29 Jan 2018 12:10:02 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: , Message-ID: “stop doing patch releases for minor releases that are not LTS.” +1 _____________________________ From: Simon Hausmann Sent: Monday, January 29, 2018 3:16 AM Subject: Re: [Development] Qt branches & proposal how to continue with those To: Jani Heikkinen , Hi, I feel that we are generally guiding our users towards the LTS releases. The minor releases appear to address in particular users who need a particular feature before it hits the next LTS release. In the light of that, I think it would be better to keep the LTS branches open longer and stop doing patch releases for minor releases that are not LTS. Simon ________________________________ From: Development on behalf of Jani Heikkinen Sent: Monday, January 29, 2018 7:59:06 AM To: development at qt-project.org Subject: [Development] Qt branches & proposal how to continue with those Hi, We have currently really many branches open: - 5.6 - 5.9 - 5.10 - 5.10.1 - 5.11 - dev In my opinion this is too much to handle effectively, especially because there is many branches in stable mode (seehttp://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is in 'strict' mode and '5.9', 5.10' & '5.11' are in stable... I think we need to change that to be able to work efficiently & get releases out. So I am proposing following changes starting from 1st Feb 2018: - '5.6' will move in 'very strict' mode - '5.9' will move in 'strict' mode. So no direct submissions anymore, just cherry picks from stable - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too long) - '5.11' will be to one and only stable branch br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan.vatra at kdab.com Mon Jan 29 13:19:00 2018 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Mon, 29 Jan 2018 14:19:00 +0200 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: <3024105.nFN0MXf5xW@zmeu> Hi, As long as we don't have enough time fix all the problems in a non LTS release, I think releasing at least one patch version is not that bad ... Yours, BogDan. În ziua de luni, 29 ianuarie 2018, la 10:15:51 EET, Simon Hausmann a scris: > Hi, > > > I feel that we are generally guiding our users towards the LTS releases. The > minor releases appear to address in particular users who need a particular > feature before it hits the next LTS release. > > > In the light of that, I think it would be better to keep the LTS branches > open longer and stop doing patch releases for minor releases that are not > LTS. > > > > Simon > > ________________________________ > From: Development > on behalf of Jani Heikkinen Sent: Monday, January > 29, 2018 7:59:06 AM > To: development at qt-project.org > Subject: [Development] Qt branches & proposal how to continue with those > > Hi, > > We have currently really many branches open: > - 5.6 > - 5.9 > - 5.10 > - 5.10.1 > - 5.11 > - dev > > In my opinion this is too much to handle effectively, especially because > there is many branches in stable mode (see > http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' > is in 'strict' mode and '5.9', 5.10' & '5.11' are in stable... I think we > need to change that to be able to work efficiently & get releases out. > > So I am proposing following changes starting from 1st Feb 2018: > > - '5.6' will move in 'very strict' mode > - '5.9' will move in 'strict' mode. So no direct submissions anymore, just > cherry picks from stable - '5.10' will be closed and Qt 5.10.1 will be the > final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we > shouldn't keep Qt 5.10 active too long) - '5.11' will be to one and only > stable branch > > br, > > Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Mon Jan 29 13:27:49 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 29 Jan 2018 15:27:49 +0300 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: <2013471517228869@web25g.yandex.ru> 29.01.2018, 11:16, "Simon Hausmann" : > Hi, > > I feel that we are generally guiding our users towards the LTS releases. The minor releases appear to address in particular users who need a particular feature before it hits the next LTS release. > > In the light of that, I think it would be better to keep the LTS branches open longer and stop doing patch releases for minor releases that are not LTS. When 5.x.0 is released, there is always a bunch of non-P0 bug fixes in 5.x branch which missed the release because of timing issues. I propose following workflow: 1) after 5.x.0 is branched, 5.x is kept open and bug fixes go there 2) after 5.x.0 is finally released, 5.x.1 branching starts immediately with usual one-week buffer time 3) after that, 5.x is closed down > > Simon > ---------------------------------------- > From: Development on behalf of Jani Heikkinen > Sent: Monday, January 29, 2018 7:59:06 AM > To: development at qt-project.org > Subject: [Development] Qt branches & proposal how to continue with those > > Hi, > > We have currently really many branches open: > - 5.6 > - 5.9 > - 5.10 > - 5.10.1 > - 5.11 > - dev > > In my opinion this is too much to handle effectively, especially because there is many branches in stable mode (see http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is in 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we need to change that to be able to work efficiently & get releases out. > > So I am proposing following changes starting from 1st Feb 2018: > > - '5.6' will move in 'very strict' mode > - '5.9' will move in 'strict' mode. So no direct submissions anymore, just cherry picks from stable > - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too long) > - '5.11' will be to one and only stable branch > > br, > > Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From Simon.Hausmann at qt.io Mon Jan 29 13:29:55 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 29 Jan 2018 12:29:55 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <2013471517228869@web25g.yandex.ru> References: , <2013471517228869@web25g.yandex.ru> Message-ID: Right, so one patch release per non-LTS minor release to fix bloopers :) Simon ________________________________ From: Konstantin Tokarev Sent: Monday, January 29, 2018 1:27:49 PM To: Simon Hausmann; Jani Heikkinen; development at qt-project.org Subject: Re: [Development] Qt branches & proposal how to continue with those 29.01.2018, 11:16, "Simon Hausmann" : > Hi, > > I feel that we are generally guiding our users towards the LTS releases. The minor releases appear to address in particular users who need a particular feature before it hits the next LTS release. > > In the light of that, I think it would be better to keep the LTS branches open longer and stop doing patch releases for minor releases that are not LTS. When 5.x.0 is released, there is always a bunch of non-P0 bug fixes in 5.x branch which missed the release because of timing issues. I propose following workflow: 1) after 5.x.0 is branched, 5.x is kept open and bug fixes go there 2) after 5.x.0 is finally released, 5.x.1 branching starts immediately with usual one-week buffer time 3) after that, 5.x is closed down > > Simon > ---------------------------------------- > From: Development on behalf of Jani Heikkinen > Sent: Monday, January 29, 2018 7:59:06 AM > To: development at qt-project.org > Subject: [Development] Qt branches & proposal how to continue with those > > Hi, > > We have currently really many branches open: > - 5.6 > - 5.9 > - 5.10 > - 5.10.1 > - 5.11 > - dev > > In my opinion this is too much to handle effectively, especially because there is many branches in stable mode (see http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is in 'strict' mode and '5.9', 5.10' & '5.11' are in stable... I think we need to change that to be able to work efficiently & get releases out. > > So I am proposing following changes starting from 1st Feb 2018: > > - '5.6' will move in 'very strict' mode > - '5.9' will move in 'strict' mode. So no direct submissions anymore, just cherry picks from stable > - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too long) > - '5.11' will be to one and only stable branch > > br, > > Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Mon Jan 29 13:33:31 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 29 Jan 2018 15:33:31 +0300 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: , <2013471517228869@web25g.yandex.ru> Message-ID: <2052661517229211@web25g.yandex.ru> 29.01.2018, 15:30, "Simon Hausmann" : > Right, so one patch release per non-LTS minor release to fix bloopers :) If there are bugs featured in "Known Issues" which can be fixed in reasonable time they could be merged directly to 5.x.1 branch after 1-week deadline as an exception. > > Simon > ---------------------------------------- > From: Konstantin Tokarev > Sent: Monday, January 29, 2018 1:27:49 PM > To: Simon Hausmann; Jani Heikkinen; development at qt-project.org > Subject: Re: [Development] Qt branches & proposal how to continue with those > > 29.01.2018, 11:16, "Simon Hausmann" : >> Hi, >> >> I feel that we are generally guiding our users towards the LTS releases. The minor releases appear to address in particular users who need a particular feature before it hits the next LTS release. >> >> In the light of that, I think it would be better to keep the LTS branches open longer and stop doing patch releases for minor releases that are not LTS. > > When 5.x.0 is released, there is always a bunch of non-P0 bug fixes in 5.x branch which missed the release because of timing issues. > > I propose following workflow: > > 1) after 5.x.0 is branched, 5.x is kept open and bug fixes go there > 2) after 5.x.0 is finally released, 5.x.1 branching starts immediately with usual one-week buffer time > 3) after that, 5.x is closed down > >> >> Simon >> ---------------------------------------- >> From: Development on behalf of Jani Heikkinen >> Sent: Monday, January 29, 2018 7:59:06 AM >> To: development at qt-project.org >> Subject: [Development] Qt branches & proposal how to continue with those >> >> Hi, >> >> We have currently really many branches open: >> - 5.6 >> - 5.9 >> - 5.10 >> - 5.10.1 >> - 5.11 >> - dev >> >> In my opinion this is too much to handle effectively, especially because there is many branches in stable mode (see http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is in 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we need to change that to be able to work efficiently & get releases out. >> >> So I am proposing following changes starting from 1st Feb 2018: >> >> - '5.6' will move in 'very strict' mode >> - '5.9' will move in 'strict' mode. So no direct submissions anymore, just cherry picks from stable >> - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too long) >> - '5.11' will be to one and only stable branch >> >> br, >> >> Jani >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> , >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin --  Regards, Konstantin From kevin.kofler at chello.at Mon Jan 29 14:32:58 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 29 Jan 2018 14:32:58 +0100 Subject: [Development] Qt branches & proposal how to continue with those References: Message-ID: Simon Hausmann wrote: > In the light of that, I think it would be better to keep the LTS branches > open longer and stop doing patch releases for minor releases that are not > LTS. -1 from a distro packager perspective. LTS just does not fit together with fast-moving distributions, and we really need those bugfix releases for the branches we ship. Especially QtWebEngine requires those bugfix releases for security fixes, and tracking LTS is not that great there because the base Chromium gets old pretty quickly, and websites start complaining (e.g., Google already complains about 5.9 being an outdated Chromium) or even stop working altogether. The frequency of LTS releases has also so far been totally insufficient to keep up with Chromium security fixes (see the huge amount of time – almost a whole year! – between 5.6.2 and 5.6.3). I would rather see LTS canceled and more effort put into the current releases, if having both is a problem. Kevin Kofler From kevin.kofler at chello.at Mon Jan 29 14:40:20 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 29 Jan 2018 14:40:20 +0100 Subject: [Development] Qt branches & proposal how to continue with those References: <8f399bb9-a01e-7fd2-4f36-38e08bcebfff@kdab.com> Message-ID: Giuseppe D'Angelo wrote: > I don't agree, 5.10 releases should be done on a regular basis until > 5.11.1 is out (Yes, .1, many users don't upgrade to .0 versions...) +1, I also agree with you and therefore disagree with the original proposal. Especially security warrants always having one current release branch active. There is one Qt component (QtWebEngine) for which it is essentially GUARANTEED that there will be security concerns to address. In addition, security issues can hit any Qt component at any time. Those MUST be addressed in a timely manner for Qt to be usable. While offering security fixes as patches attached to security advisories can work for some components, this is not always workable. In particular, QtWebEngine just cannot be handled that way. And of course, there can also be other bugs that users will want fixed sooner rather than later. Kevin Kofler From paolo.angelelli at qt.io Mon Jan 29 14:41:53 2018 From: paolo.angelelli at qt.io (Paolo Angelelli) Date: Mon, 29 Jan 2018 14:41:53 +0100 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <8f399bb9-a01e-7fd2-4f36-38e08bcebfff@kdab.com> References: <8f399bb9-a01e-7fd2-4f36-38e08bcebfff@kdab.com> Message-ID: <20180129144153.207194ee@qdesktop> On Mon, 29 Jan 2018 10:31:14 +0100 Giuseppe D'Angelo wrote: > On 29/01/18 07:59, Jani Heikkinen wrote: > > We have currently really many branches open: > > - 5.6 > > - 5.9 > > - 5.10 > > - 5.10.1 > > - 5.11 > > - dev > > > > In my opinion this is too much to handle effectively, especially because there is many branches in stable mode (see http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' is in 'strict' mode and '5.9', 5.10' & '5.11' are in stable... I think we need to change that to be able to work efficiently & get releases out. > > Could you please elaborate, what's the problem at the moment when you > say that it's "too much" to handle? Is it a matter that branches have > become different enough that merges don't apply any longer? Is it a > matter of bandwidth for the releasing team having to produce releases > from several branches? > > > > > So I am proposing following changes starting from 1st Feb 2018: > > > > - '5.6' will move in 'very strict' mode > > Which by the way is already the case, in practice. E.g. there have been > ~20-30 patches landing in qtbase/5.6, with over half being fixes for > flaky autotests. > > > - '5.9' will move in 'strict' mode. So no direct submissions anymore, just cherry picks from stable > > This was also proposed a few days ago (to change in 'strict' mode after > 5.11 branching is completed). I have mixed feelings about that, in the > sense that in 6 months from now noone will be doing the cherry-picks > because of the extra work, thus leaving bugs in 5.9 in the name of > stability, but somehow breaks the LTS promise. +1 This will also introduce extra work in patching 5.9 (every change that has to go to 5.9 has to be pushed twice, due to no more forward merges) > > > - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too long) > > I don't agree, 5.10 releases should be done on a regular basis until > 5.11.1 is out (Yes, .1, many users don't upgrade to .0 versions...) +1 here too Closing 5.10 before 5.11 isn't even released, and actually after just 2 months of releasing, also doesn't seem good marketing material for the project.. > > My 2 cents, From me at the-compiler.org Mon Jan 29 15:04:45 2018 From: me at the-compiler.org (Florian Bruhin) Date: Mon, 29 Jan 2018 15:04:45 +0100 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: <20180129140445.jxarnownifzypcq2@hooch.localdomain> On Mon, Jan 29, 2018 at 02:32:58PM +0100, Kevin Kofler wrote: > Simon Hausmann wrote: > > In the light of that, I think it would be better to keep the LTS branches > > open longer and stop doing patch releases for minor releases that are not > > LTS. > > -1 from a distro packager perspective. LTS just does not fit together with > fast-moving distributions, and we really need those bugfix releases for the > branches we ship. > > Especially QtWebEngine requires those bugfix releases for security fixes, > and tracking LTS is not that great there because the base Chromium gets old > pretty quickly, and websites start complaining (e.g., Google already > complains about 5.9 being an outdated Chromium) or even stop working > altogether. The frequency of LTS releases has also so far been totally > insufficient to keep up with Chromium security fixes (see the huge amount of > time – almost a whole year! – between 5.6.2 and 5.6.3). > > I would rather see LTS canceled and more effort put into the current > releases, if having both is a problem. I can't agree more - while I'm not a distro packager, I'm a maintainer of an opensource project[1] using QtWebEngine. 5.x.0 releases are often quite painful, as they're full of regressions introduced because of new Chromium versions. I try to find report those as soon as possible, but there are always issues ([2] for an example) which only surface after a release. Like Kevin said, of course security updates are also a big issue, and only getting them all 6 months is definitely not good... Florian [1] https://www.qutebrowser.org/ [2] https://bugreports.qt.io/browse/QTBUG-65223 -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From annulen at yandex.ru Mon Jan 29 15:41:55 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 29 Jan 2018 17:41:55 +0300 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: <358711517236915@web9g.yandex.ru> 29.01.2018, 16:33, "Kevin Kofler" : > Simon Hausmann wrote: >>  In the light of that, I think it would be better to keep the LTS branches >>  open longer and stop doing patch releases for minor releases that are not >>  LTS. > > -1 from a distro packager perspective. LTS just does not fit together with > fast-moving distributions, and we really need those bugfix releases for the > branches we ship. > > Especially QtWebEngine requires those bugfix releases for security fixes, > and tracking LTS is not that great there because the base Chromium gets old > pretty quickly, and websites start complaining (e.g., Google already > complains about 5.9 being an outdated Chromium) or even stop working > altogether. The frequency of LTS releases has also so far been totally > insufficient to keep up with Chromium security fixes (see the huge amount of > time – almost a whole year! – between 5.6.2 and 5.6.3). > > I would rather see LTS canceled and more effort put into the current > releases, if having both is a problem. Note that you can build newer QtWebEngine releases against LTS Qt > >         Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Mon Jan 29 17:11:14 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Jan 2018 08:11:14 -0800 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> On segunda-feira, 29 de janeiro de 2018 04:10:02 PST Adam Treat wrote: > “stop doing patch releases for minor releases that are not LTS.” > > +1 So long as we "stop after the .1" Just look at how many distributions skipped 5.8 entirely because it didn't have a .1. That was a huge mistake on our part. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Mon Jan 29 17:15:14 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 29 Jan 2018 17:15:14 +0100 Subject: [Development] Qt branches & proposal how to continue with those References: <358711517236915@web9g.yandex.ru> Message-ID: Konstantin Tokarev wrote: > Note that you can build newer QtWebEngine releases against LTS Qt I know, and I am already doing this, but this does not help if there is no newer QtWebEngine release to begin with! Even taking a snapshot is typically not an option because security fixes are only backported in batches when a release is imminent (and in any case, will never be backported to a closed release branch). If QtWebEngine releases actually get decoupled from Qt releases, that could address this issue, but as things are now, the Qt bugfix releases are needed for QtWebEngine. Kevin Kofler From tuukka.turunen at qt.io Mon Jan 29 22:05:10 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 29 Jan 2018 21:05:10 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> Message-ID: <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> Hi, To comment a bit this discussion, I think that with Qt 5.10 as the first release after the LTS it might be fine to stop after .1, but in general I would not want to set such a rule. To me the question at hand is should we skip Qt 5.10.2 release if that means we can put more fixes into Qt 5.9.x and manage to release Qt 5.11 in time? As Jani pointed out the challenge is number of stable branches and the needed amount of merges. Users prefer LTS releases, so focusing the effort to have more bug fixes and patch releases for the LTS release rather than the LTS+1 release benefits a higher amount of users than the other way around. That said, we should not continue to push majority of fixes to Qt 5.9 too long as that is also counterproductive for the need to have a rock solid LTS release. Yours, Tuukka On 29/01/2018, 18.11, "Development on behalf of Thiago Macieira" wrote: On segunda-feira, 29 de janeiro de 2018 04:10:02 PST Adam Treat wrote: > “stop doing patch releases for minor releases that are not LTS.” > > +1 So long as we "stop after the .1" Just look at how many distributions skipped 5.8 entirely because it didn't have a .1. That was a huge mistake on our part. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From kevin.kofler at chello.at Tue Jan 30 00:18:50 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 30 Jan 2018 00:18:50 +0100 Subject: [Development] Qt branches & proposal how to continue with those References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> Message-ID: Tuukka Turunen wrote: > Users prefer LTS releases According to what statistics? Also keep in mind that distributions will download Qt once and redistribute it to thousands of users. And also that there are 2 classes of Qt users: application developers and end users. Such a bold claim really ought to be more substantiated than that. I would on the contrary expect users to want new features sooner rather than later, also considering that Qt is almost 100% backwards compatible from one release to the next anyway, but that is just a feeling with no statistics at all. Kevin Kofler From tuukka.turunen at qt.io Tue Jan 30 06:57:38 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 30 Jan 2018 05:57:38 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> Message-ID: Hi, This is not an either-or thing. Of course both having new feature releases and stable LTS are important. I am not claiming otherwise. My point is that there are more users for the LTS versions, thus I used the expression. There are a lot of users for both, we do not need to have a poll to know that these are both important. I still would like to emphasize the point I made in my e-mail: this is to me specifically about what do we do to Qt 5.10 branch after release of Qt 5.10.1. Not about stopping patch releases altogether for other than LTS. Yours, Tuukka On 30/01/2018, 1.19, "Development on behalf of Kevin Kofler" wrote: Tuukka Turunen wrote: > Users prefer LTS releases According to what statistics? Also keep in mind that distributions will download Qt once and redistribute it to thousands of users. And also that there are 2 classes of Qt users: application developers and end users. Such a bold claim really ought to be more substantiated than that. I would on the contrary expect users to want new features sooner rather than later, also considering that Qt is almost 100% backwards compatible from one release to the next anyway, but that is just a feeling with no statistics at all. Kevin Kofler _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Jan 30 07:22:56 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Jan 2018 22:22:56 -0800 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: <1828719.DlCZl1ANza@tjmaciei-mobl1> On segunda-feira, 29 de janeiro de 2018 21:57:38 PST Tuukka Turunen wrote: > Hi, > > This is not an either-or thing. Of course both having new feature releases > and stable LTS are important. I am not claiming otherwise. My point is that > there are more users for the LTS versions, thus I used the expression. And that's exactly what Kevin objected: you don't present any data to say that there are more for LTS compared to others. All we know is that there are users for both and we also know that there are some users who cannot upgrade because we dropped platforms in both 5.10 an 5.11. > I still would like to emphasize the point I made in my e-mail: this is to me > specifically about what do we do to Qt 5.10 branch after release of Qt > 5.10.1. Not about stopping patch releases altogether for other than LTS. My opinion is: we continue it until at least 5.11.0. I understand that there are a lot of branches, but most of them have little to no activity: qtbase $ git rev-list --count --since=6.months.ago origin/5.6 21 qtbase $ git rev-list --count --since=3.months.ago origin/5.6 7 qtdeclarative $ git rev-list --count --since=6.months.ago origin/5.6 8 qtdeclarative $ git rev-list --count --since=3.months.ago origin/5.6 1 All of Qt 5.6 has 44 commits total for the last 6 months, 8 in the last three. That also means only two repositories in 5.6 changed in the last three months: qtbase and qtdeclarative. The time between the last and the second-to-last commits in qtbase was over a month. So at this point 5.6 basically doesn't count. So we effectively have open 5.9, 5.10, 5.11 and dev, which is the same quantity as just after the 5.8 branching (5.6, 5.7, 5.8 and dev). And that's exactly what led to the worst release of all: 5.8.0. Let's not repeat that mistake. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Tue Jan 30 07:40:02 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 30 Jan 2018 06:40:02 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Kevin Kofler > Sent: maanantai 29. tammikuuta 2018 15.33 > To: development at qt-project.org > Subject: Re: [Development] Qt branches & proposal how to continue with those > > Simon Hausmann wrote: > > In the light of that, I think it would be better to keep the LTS > > branches open longer and stop doing patch releases for minor releases > > that are not LTS. > > -1 from a distro packager perspective. LTS just does not fit together with fast- > moving distributions, and we really need those bugfix releases for the branches > we ship. I have to disagree there: We have already released 4 patch level releases for LTS 5.9 so it is actually moving quite fast. br, Jani From tony.sarajarvi at qt.io Tue Jan 30 11:20:20 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Tue, 30 Jan 2018 10:20:20 +0000 Subject: [Development] CI infra broken Message-ID: Hi We have problems with our infra currently. We're working on it. For the time being, the CI is down. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From konrad at silmor.de Tue Jan 30 11:26:12 2018 From: konrad at silmor.de (Konrad Rosenbaum) Date: Tue, 30 Jan 2018 11:26:12 +0100 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> Message-ID: <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> On Tue, January 30, 2018 00:18, Kevin Kofler wrote: > I would on the contrary expect users to want new features sooner rather > than > later, [...] Please keep in mind that there are several classes of Qt users: Mobile: moving fast and furious. Depend on novelty. General Desktop: moving somewhat fast. Prefer novelty. Offices w/ IT admins: move much slower. Prefer stability over novelty. Industrial, regulated and embedded: move extremely slow. Depend on stability. I've been in projects that jumped ship every time someone invented a new buzz word and in projects where I had to compile my own GCC and X11 libraries because no supported version of Qt would compile with the one(s) in the target OS. Konrad From tony.sarajarvi at qt.io Tue Jan 30 14:35:31 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Tue, 30 Jan 2018 13:35:31 +0000 Subject: [Development] CI infra broken In-Reply-To: References: Message-ID: Hi Seems we ran out of luck again. The openNebula VM seems to be broken. We reached a bug in vSphere that's still unresolved by VMware. We have to recreate the VM, and that will take some time. Estimate for getting the CI up is tomorrow. WR, -Tony From: Tony Sarajärvi Sent: tiistai 30. tammikuuta 2018 12.20 To: 'development at qt-project.org' Subject: CI infra broken Hi We have problems with our infra currently. We're working on it. For the time being, the CI is down. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From master.of.m42 at gmail.com Tue Jan 30 19:42:10 2018 From: master.of.m42 at gmail.com (MASTER OF ORION) Date: Tue, 30 Jan 2018 21:42:10 +0300 Subject: [Development] [QtRO] Qt Remote Objects Security and Encryption Message-ID: Hi guys! On how many I have understood QtRO, now generally there is no possibility somehow to protect server objects like QRemoteObjectRegistryHost or QRemoteObjectHost from hackers access via internet? Look, i'm creating an QRemoteObjectRegistryHost object, it just listen a port (probably through the QTcpServer) and absolutely any client from any computer can access this object through internet ... It's not good... It's only suitable for the IPC within a single computer. Do you have plans to add authorization mechanism to QRemoteObjectRegistryHost? And if you add even the ability to encrypt the data through (e.g. RSA), it will be generally an miracle! Guys, do it please :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Tue Jan 30 22:38:29 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 30 Jan 2018 21:38:29 +0000 Subject: [Development] Qt branches & proposal how to continue with those In-Reply-To: <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> References: <4137226.H1Wp0KbUjd@tjmaciei-mobl1> <3586F83C-F715-4B4E-BFA1-A24EF62946FA@qt.io> <833e801049d7d35ed1dab558afafd7fb.squirrel@squirrel.six.silmor.de> Message-ID: <45E55A9F-D3E3-4FC4-B239-74E2BBBA7AFC@qt.io> Hi, What Keven wrote below is absolutely true. Within the one million users of Qt we really have an extremely wide variety of different needs. Also in this discussion, there has been quite a versatile set of opinions stated, which is very good. There has been some suggestions to even not make patch releases at all for non-LTS releases (which is way more scarce on releases that Jani initially suggested). There has been some discussion about which is more important to have patch releases for: LTS or non-LTS versions. Luckily we are not in a situation where we would have to choose. Both are important and it is very natural that an LTS will receive more patch level releases than a non-LTS release. Here is what Jani originally proposed (to happen starting from 1st Feb 2018): - '5.6' will move in 'very strict' mode - '5.9' will move in 'strict' mode. So no direct submissions anymore, just cherry picks from stable - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 active too long) - '5.11' will be to one and only stable branch The item that has received comments both in favor and against is what to do with 5.10 now. I think that instead of closing 5.10, we could move it to cherry pick mode, just like Qt 5.9 is. That allows putting the necessary fixes there, but reduces the amount of needed merges a lot. It also allows to faster get all the fixes merged up to dev, which is something we have struggled in the past. With this approach we have full capability to make Qt 5.10.2 release, if one is needed. We also continue to make Qt 5.9.x patch releases. We would have two branches open for direct submission: 5.11 and dev, and for each commit the lowest applicable branch can be chosen. For all such important fixes that need to be in Qt 5.9.x LTS releases or in the 5.10 branch, we use cherry picking. Yours, Tuukka On 30/01/2018, 12.27, "Development on behalf of Konrad Rosenbaum" wrote: On Tue, January 30, 2018 00:18, Kevin Kofler wrote: > I would on the contrary expect users to want new features sooner rather > than > later, [...] Please keep in mind that there are several classes of Qt users: Mobile: moving fast and furious. Depend on novelty. General Desktop: moving somewhat fast. Prefer novelty. Offices w/ IT admins: move much slower. Prefer stability over novelty. Industrial, regulated and embedded: move extremely slow. Depend on stability. I've been in projects that jumped ship every time someone invented a new buzz word and in projects where I had to compile my own GCC and X11 libraries because no supported version of Qt would compile with the one(s) in the target OS. Konrad _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From tony.sarajarvi at qt.io Tue Jan 30 23:13:08 2018 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Tue, 30 Jan 2018 22:13:08 +0000 Subject: [Development] CI infra broken In-Reply-To: References: Message-ID: Hi We worked around the bug, but it took hours to move all data involved here. The system is back up and running now. You might have noticed quite a few provisioning failures (details show a proxy problem) failing your builds right after I got things up and running. Two things here. The proxy was never launched after we migrated it. An oversight on our part. Secondly the provisioning scripts have a check whether or not a proxy is available. I had created a bug there. Sorry about that. I have a fix created now for that. Anyway, just restage the commits and things should roll again. I did that for a few of the tasks for you :) The earlier e-mail about CI updates ongoing where I mentioned that the capacity is lower than usual for the time being. That’s still the situation. This day just caused delays there. We’re now at 50%, but we should be at 75% or so in the morning. Hopefully during tomorrow we’ll have all hosts available again…with the new version of openNebula running newer KVM hosts (hopefully more stable). A lot of hopes there 😝 With regards, -Tony From: Tony Sarajärvi Sent: tiistai 30. tammikuuta 2018 14.33 To: 'development at qt-project.org' Subject: RE: CI infra broken Hi Seems we ran out of luck again. The openNebula VM seems to be broken. We reached a bug in vSphere that’s still unresolved by VMware. We have to recreate the VM, and that will take some time. Estimate for getting the CI up is tomorrow. WR, -Tony From: Tony Sarajärvi Sent: tiistai 30. tammikuuta 2018 12.20 To: 'development at qt-project.org' > Subject: CI infra broken Hi We have problems with our infra currently. We’re working on it. For the time being, the CI is down. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From allan.jensen at qt.io Tue Jan 30 23:16:34 2018 From: allan.jensen at qt.io (Allan Sandfeld Jensen) Date: Tue, 30 Jan 2018 23:16:34 +0100 Subject: [Development] CI infra broken In-Reply-To: References: Message-ID: <18971750.UnlHpy76ms@twilight> On Dienstag, 30. Januar 2018 23:13:08 CET Tony Sarajärvi wrote: > Hi > > We worked around the bug, but it took hours to move all data involved here. > The system is back up and running now. It appears to still be broken just like it was before everything went offline, half the CIs can't provision and fail with messages like: E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/p/python3.5/ libpython3.5_3.5.2-2ubuntu0~16.04.4_amd64.deb Could not connect to proxy.intra.qt.io:3128 (10.215.0.6). - connect (113: No route to host) 'Allan From kevin.kofler at chello.at Wed Jan 31 04:13:28 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 31 Jan 2018 04:13:28 +0100 Subject: [Development] Qt branches & proposal how to continue with those References: Message-ID: Jani Heikkinen wrote: > I have to disagree there: We have already released 4 patch level releases > for LTS 5.9 so it is actually moving quite fast. That is not what I meant with fast-moving! Those LTS patch releases by design do not provide the new features that the releases from higher branches provide. When I write "fast-moving distribution", I mean a distribution that focuses on getting features to its users as quickly as possible, as opposed to the conservative "enterprise" distributions that are the ones actually interested in LTS branches of upstream software. And even when it comes to bug (and security!) fixes, for how long are you going to keep up this pace of 5.9.x releases? In the previous LTS series, there was almost a whole year between 5.6.2 and 5.6.3. QtWebEngine CVEs kept piling up in that time. Kevin Kofler From tony.sarajarvi at qt.io Wed Jan 31 05:42:35 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Wed, 31 Jan 2018 04:42:35 +0000 Subject: [Development] CI infra broken In-Reply-To: <18971750.UnlHpy76ms@twilight> References: <18971750.UnlHpy76ms@twilight> Message-ID: Hi Now that seems to be a bug in Coin. It doesn't even begin to retry it. The log is still from last night the first time I launched it. Sigh... I'll try to force it somehow. -Tony -----Original Message----- From: Allan Jensen Sent: keskiviikko 31. tammikuuta 2018 0.17 To: Tony Sarajärvi Cc: development at qt-project.org Subject: Re: CI infra broken On Dienstag, 30. Januar 2018 23:13:08 CET Tony Sarajärvi wrote: > Hi > > We worked around the bug, but it took hours to move all data involved here. > The system is back up and running now. It appears to still be broken just like it was before everything went offline, half the CIs can't provision and fail with messages like: E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/p/python3.5/ libpython3.5_3.5.2-2ubuntu0~16.04.4_amd64.deb Could not connect to proxy.intra.qt.io:3128 (10.215.0.6). - connect (113: No route to host) 'Allan From jani.heikkinen at qt.io Wed Jan 31 10:26:23 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 31 Jan 2018 09:26:23 +0000 Subject: [Development] Qt 5.10.1 changes files Message-ID: Hi, Initial versions done, see https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.10.1%22+status:open,n,z Maintainers: Please finalize & get '+2' as soon as possible br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.klocek at qt.io Wed Jan 31 11:44:23 2018 From: michal.klocek at qt.io (Michal Klocek) Date: Wed, 31 Jan 2018 11:44:23 +0100 Subject: [Development] CI infra broken In-Reply-To: References: <18971750.UnlHpy76ms@twilight> Message-ID: <964d5ae0-20d0-e61d-02da-247d00702511@qt.io> Hi Please let us know if we can use ci already or not. I also get: "Timeout while creating source archives. Probably Coin issue, you can re-stage and ping Coin admin." Br Michal On 01/31/2018 05:42 AM, Tony Sarajärvi wrote: > Hi > > Now that seems to be a bug in Coin. It doesn't even begin to retry it. The log is still from last night the first time I launched it. Sigh... I'll try to force it somehow. > > -Tony > > -----Original Message----- > From: Allan Jensen > Sent: keskiviikko 31. tammikuuta 2018 0.17 > To: Tony Sarajärvi > Cc: development at qt-project.org > Subject: Re: CI infra broken > > On Dienstag, 30. Januar 2018 23:13:08 CET Tony Sarajärvi wrote: >> Hi >> >> We worked around the bug, but it took hours to move all data involved here. >> The system is back up and running now. > > It appears to still be broken just like it was before everything went offline, half the CIs can't provision and fail with messages like: > > E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/p/python3.5/ > libpython3.5_3.5.2-2ubuntu0~16.04.4_amd64.deb Could not connect to > proxy.intra.qt.io:3128 (10.215.0.6). - connect (113: No route to host) > > > > 'Allan > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From jani.heikkinen at qt.io Wed Jan 31 11:57:21 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 31 Jan 2018 10:57:21 +0000 Subject: [Development] Final downmerge from dev to '5.11' delayed Message-ID: Hi all, Most probably there is changes in 'dev' which should be in Qt 5.11 but which aren't yet integrated because of CI issues recently. That's why let's postpone final downmerge (and Qt 5.11 FF) to the end of this week. New plan is to have final downmerge from 'dev' to '5.11' (and Qt 5.11 FF) Monday 5.2.2018 (morning). Hoping CI will behave now and you have enough time to get needed changes in before final downmerge. And remember: This delay is just to get changes in, not for getting extra time for new implementation! br, Jani > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Jani Heikkinen > Sent: torstai 25. tammikuuta 2018 8.58 > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: [Development] Branching from 'dev' to '5.11' started > > Hi, > > We have now soft branched '5.11' from dev so please start using '5.11' now. Qt > 5.11 feature freeze and final downmerge from 'dev' to '5.11' will happen Wed > 31.1.2018 so there is still enough time to finalize ongoing changes in 'dev'. > > And let's keep the feature freeze now, it is key enabler for us to be able to keep > the release schedule. So it is time to check if new feature can be finalized early > enough for the feature freeze. If not then we should just postpone it to Qt 5.12 > instead of trying to get it in Qt 5.11. > > br, > Jani Heikkinen > Release Manager > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tony.sarajarvi at qt.io Wed Jan 31 12:41:51 2018 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Wed, 31 Jan 2018 11:41:51 +0000 Subject: [Development] CI infra broken In-Reply-To: <964d5ae0-20d0-e61d-02da-247d00702511@qt.io> References: <18971750.UnlHpy76ms@twilight> <964d5ae0-20d0-e61d-02da-247d00702511@qt.io> Message-ID: Hi Yes you may use it, but it's currently in the state where stores are in the morning of Black Friday. We have everyone running in now and wondering why they don't get service. Talking about the commits you push in. Enormous peaks here. On top of that, I deleted all tier2 images everywhere. Basically meaning that the stores has nothing placed in shelves but everything has to be brought out from the back. I should have done that before I opened everything. I also found that qtbase's autotest fail because the network test server has some problems after the restart. Looking into that. It often doesn't like reboots and fails when launching services. Shouldn't take long to fix. -T -----Original Message----- From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Michal Klocek Sent: keskiviikko 31. tammikuuta 2018 12.44 To: development at qt-project.org Subject: Re: [Development] CI infra broken Hi Please let us know if we can use ci already or not. I also get: "Timeout while creating source archives. Probably Coin issue, you can re-stage and ping Coin admin." Br Michal On 01/31/2018 05:42 AM, Tony Sarajärvi wrote: > Hi > > Now that seems to be a bug in Coin. It doesn't even begin to retry it. The log is still from last night the first time I launched it. Sigh... I'll try to force it somehow. > > -Tony > > -----Original Message----- > From: Allan Jensen > Sent: keskiviikko 31. tammikuuta 2018 0.17 > To: Tony Sarajärvi > Cc: development at qt-project.org > Subject: Re: CI infra broken > > On Dienstag, 30. Januar 2018 23:13:08 CET Tony Sarajärvi wrote: >> Hi >> >> We worked around the bug, but it took hours to move all data involved here. >> The system is back up and running now. > > It appears to still be broken just like it was before everything went offline, half the CIs can't provision and fail with messages like: > > E: Failed to fetch > http://security.ubuntu.com/ubuntu/pool/main/p/python3.5/ > libpython3.5_3.5.2-2ubuntu0~16.04.4_amd64.deb Could not connect to > proxy.intra.qt.io:3128 (10.215.0.6). - connect (113: No route to host) > > > > 'Allan > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From tony.sarajarvi at qt.io Wed Jan 31 14:12:57 2018 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Wed, 31 Jan 2018 13:12:57 +0000 Subject: [Development] CI infra broken In-Reply-To: References: <18971750.UnlHpy76ms@twilight> <964d5ae0-20d0-e61d-02da-247d00702511@qt.io> Message-ID: Finally figured out the problem with the network test server. Sorry about the delay. QtBase's autotests have a greater chance of passing again (note: didn't say they will pass 😉) -Tony -----Original Message----- From: Tony Sarajärvi Sent: keskiviikko 31. tammikuuta 2018 13.42 To: 'Michal Klocek' ; development at qt-project.org Subject: RE: [Development] CI infra broken Hi Yes you may use it, but it's currently in the state where stores are in the morning of Black Friday. We have everyone running in now and wondering why they don't get service. Talking about the commits you push in. Enormous peaks here. On top of that, I deleted all tier2 images everywhere. Basically meaning that the stores has nothing placed in shelves but everything has to be brought out from the back. I should have done that before I opened everything. I also found that qtbase's autotest fail because the network test server has some problems after the restart. Looking into that. It often doesn't like reboots and fails when launching services. Shouldn't take long to fix. -T -----Original Message----- From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Michal Klocek Sent: keskiviikko 31. tammikuuta 2018 12.44 To: development at qt-project.org Subject: Re: [Development] CI infra broken Hi Please let us know if we can use ci already or not. I also get: "Timeout while creating source archives. Probably Coin issue, you can re-stage and ping Coin admin." Br Michal On 01/31/2018 05:42 AM, Tony Sarajärvi wrote: > Hi > > Now that seems to be a bug in Coin. It doesn't even begin to retry it. The log is still from last night the first time I launched it. Sigh... I'll try to force it somehow. > > -Tony > > -----Original Message----- > From: Allan Jensen > Sent: keskiviikko 31. tammikuuta 2018 0.17 > To: Tony Sarajärvi > Cc: development at qt-project.org > Subject: Re: CI infra broken > > On Dienstag, 30. Januar 2018 23:13:08 CET Tony Sarajärvi wrote: >> Hi >> >> We worked around the bug, but it took hours to move all data involved here. >> The system is back up and running now. > > It appears to still be broken just like it was before everything went offline, half the CIs can't provision and fail with messages like: > > E: Failed to fetch > http://security.ubuntu.com/ubuntu/pool/main/p/python3.5/ > libpython3.5_3.5.2-2ubuntu0~16.04.4_amd64.deb Could not connect to > proxy.intra.qt.io:3128 (10.215.0.6). - connect (113: No route to host) > > > > 'Allan > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development