Re: [Development] Adding new third party component three.js to Qt?
On Thu, Jan 15, 2015 at 05:48:16PM -0800, Thiago Macieira wrote: But what if we ship source and the generated minified files? as you are bringing up the example of includes below ... shipping as in in the tar balls is fine by me. but don't commit the minified (== generated) file to the repository. We do that for other sources that seldomly change, like the outputs from qlalr. bad example ... the only reason why we still do that is because qmake is too daft to be able to properly integrate qlalr into the build process (dependency tracking ...). this cannot be said for a lot of other generated files, for which their presence in the repository is pretty much historical only. don't add to that history. We also ship generated docs and the generated include/ headers. That's for ease of building, not for hiding anything. Remember we have trouble even asking for Perl to be present during build. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding new third party component three.js to Qt?
On Thursday 15 January 2015 20:31:58 Thiago Macieira wrote: On Friday 16 January 2015 00:54:31 Lisandro Damián Nicanor Pérez Meyer wrote: We do that for other sources that seldomly change, like the outputs from qlalr. We also ship generated docs and the generated include/ headers. That's for ease of building, not for hiding anything. Remember we have trouble even asking for Perl to be present during build. Before answering this one please note that I understand why you do this and why you would prefer to keep doing it. It happens that distros like Debian (and for what I read, also Fedora) think differently. I think you need to get some leeway and not think in absolute terms. Yes, my bad. I actually spent quite some time to try to correctly phrase this paragraph trying to express that I'm not trying to force anything nor generate a debate nor bad faith nor... but it seems I failed :-/ Allow me to blame the fact that I'm not a native speaker and I live at least 1000km away from the nearest english-speaking country ;) I realize we in Debian might be missing to regenerate some stuff (maybe quite a lot) but when we find stuff that has been pre-generated we do our best to re generate it during the build process. Do you remove and regenerate: - the Unicode tables in qunicodedata.cpp? - the CLDR data in qlocale_data_p.h and qtimezoneprivate_data_p.h? How about the locale list in qlocale.h? - the indexed string tables in qdbuserror.cpp, qbenchmarkperfevents.cpp, qxmlstream.cpp, and qsimd.cpp? - the QML parser from qmljs.g? - the XML parser from qxmlstream.g? (note the cyclic dependency, since qlalr depends on QtCore) - the pre-generated IAccessible2 interfaces (Windows-only, think of cross- mingw) - the class list in tools/uic/ui4.h? And this is just qtbase. I'm sure there are more. We are possibly missing quite a lot of them, but having a list of things to look at really helps. Thanks! Doesn't it suffice to know that you can regenerate the generated code? Even the ones you can regenerate perfectly, down to the same indentation? There's actually one thing we maintainers are allowed to do: recreate the original tarball regenerating all the necessary files and then ship that. It's a compromise solution, but if we can add those steps directly in the build process the better. Doc is an example, we Debian maintainers need to ensure that every piece we ship is in it's preferred form of modification and that we are able to create the resulting stuff ourselves with the tools in the archive. So pregenerated doc is not a solution for us. I'm not saying it was a solution. I'm saying it is a convenience. Well, a convenience we can't use then. Anyone: if you find something that needs regenerating and we (again, Debian) are not doing it, do not hesitate to fill a serious bug in Debian's bug tracker. Or ping me if you somehow find it and you are not using Debian. See above. Most of it requires manual editing to insert the resulting output back into the source code. Ah, let's hold on a little here. Up to this point I was *always* referring to stuff that gets 100% created after some process, like javascript minification. Stuff that needs hand editing *is* special, as one could consider it as the preferred form of modification. It might be a gray area, but if somebody has to fiddle with some data to create the source code then we trust upstream in this in the same way we trust for the 100% hand-coded stuff. If there is a free tool which can be used instead of the non-free one we will do our best to use it, even if the result is sub-par. Else we would prefer to simply remove the offending file and tell our users sorry, but it needs a non-free tool to build. Putting Qt in the contrib repo is a much worst user disservice than not shipping the file (and again, in Debian terms). Thanks for the info. We all agree we don't want that to happen. That's why we're discussing now, so we can find a solution that works for the packagers, like we did in the past for qtchooser (a solution designed for distro's needs). *My pleasure*. And thanks *a lot* for pointing those files above. I'll filter out those that need manual editing and see what I can do with the rest of them. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] NOTE: Gerrit server update
Hi, Gerrit server will change to new location during week 4. URL remains unchanged (https://codereview.qt-project.org/). Also some fixes will be deployed: https://bugreports.qt.io/browse/QTQAINFRA-874 https://bugreports.qt.io/browse/QTQAINFRA-892 https://bugreports.qt.io/browse/QTQAINFRA-905 https://bugreports.qt.io/browse/QTQAINFRA-906 https://bugreports.qt.io/browse/QTQAINFRA-909 Cheers, Ismo Haataja ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSsl: finer-grained protocol selection
On Sun, Dec 28, 2014 at 2:26 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Sunday 28 December 2014 13:11:13 Richard Moore wrote: At the moment there are still a lot of SSL accelerators out there with these problems. We can probably stop worrying in around a year once all the browsers have got around to disabling SSL3 and thereby forcing things to be fixed. Currently we will already fail to connect to these servers, but the API we provide allows users to implement workarounds in their own code. If we change the meaning of the TLSv1 constant in this way then it would no longer be possible for them to do this. Ah, I see. Then we just add to the list: TlsV1_0OrLater, TlsV1_1OrLater, TlsV1_2OrLater When TLS 1.3 comes into existence, we add: TlsV1_3, TlsV1_3OrLater We'd be fine with either of these proposals. However, I think this proposal would be less surprising to existing users of QSslSocket, so it's the one I'd prefer personally. Alternatively, we can add a /// if major == 0, sets to Secure Protocols void setMinimumTlsVersion(int major, int minor); int sessionTlsMajorVersion() const; int sessionTlsMinorVersion() const; And deprecate setProtocol. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding new third party component three.js to Qt?
On Thursday 15 January 2015 20:31:58 Thiago Macieira wrote: Do you remove and regenerate: - the Unicode tables in qunicodedata.cpp? - the CLDR data in qlocale_data_p.h and qtimezoneprivate_data_p.h? How about the locale list in qlocale.h? - the indexed string tables in qdbuserror.cpp, qbenchmarkperfevents.cpp, qxmlstream.cpp, and qsimd.cpp? - the QML parser from qmljs.g? - the XML parser from qxmlstream.g? (note the cyclic dependency, since qlalr depends on QtCore) - the pre-generated IAccessible2 interfaces (Windows-only, think of cross- mingw) - the class list in tools/uic/ui4.h? And this is just qtbase. I'm sure there are more. More in qtbase: - src/tools/moc/(pp)keywords.cpp generated by the generator in src/tools/moc/util (circular dependency again) - src/corelib/io/qurltlds_p.h generated by util/corelib/qurl-generateTLDs (BTW, this really need to be regenerated, for security reasons) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding new third party component three.js to Qt?
On Friday 16 January 2015 15:35:02 Olivier Goffart wrote: [snip] More in qtbase: Thanks a lot! - src/tools/moc/(pp)keywords.cpp generated by the generator in src/tools/moc/util (circular dependency again) If you mean that those cpp are needed in order to build the tools that will later build the files themselves then it's not a problem to accept pregenerated stuff to bootstrap it because we can end up rebuilding everything. - src/corelib/io/qurltlds_p.h generated by util/corelib/qurl-generateTLDs (BTW, this really need to be regenerated, for security reasons) Then I'll start with this one :) -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] HEADS UP: Qt 5.4.1 release coming
5.4 has been downmerged to 5.4.1 now. staging in the latter is now restricted to the release team. On Thu, Jan 08, 2015 at 12:55:54PM +, Heikkinen Jani wrote: Hi! And Happy New Year to you all! '5.4.1' branch is now available, please start using it for the changes targeted to Qt5.4.1 release. As written below we will merge '5.4' branch to '5.4.1' Friday 16th January so there should be enough time to finalize ongoing changes in '5.4'. All new changes for Qt5.4.1 should be done in '5.4.1' branch from now on. Br, Jani From: development-bounces+jani.heikkinen=theqtcompany@qt-project.org [mailto:development-bounces+jani.heikkinen=theqtcompany@qt-project.org] On Behalf Of Heikkinen Jani Sent: 22. joulukuuta 2014 8:05 To: development@qt-project.org Cc: releas...@qt-project.org Subject: [Development] HEADS UP: Qt 5.4.1 release coming Importance: High Hi all, Unfortunately there has been some severe issues in Qt 5.4.0 release so we need to start preparing Qt 5.4.1 release a bit earlier than planned. We are hoping we could put 5.4.1 out already during January and so on we need to branch '5.4.1' from '5.4' latest 16.1.2015. We will use 'soft branching' scheme like we did with 5.4.0 meaning Qt 5.4.1 branch will be created (latest) during week 2/2015 and downmerge from '5.4' to '5.4.1' will be done Friday 16th January 2015. That way everyone should have enough time to finalize ongoing changes in '5.4' branch start using '5.4.1' branch for the changes targeted to Qt 5.4.1 release. After 16th Jan '5.4' is for changes targeted to 5.4.2. And remember, we are doing patch level release now meaning do not put any new features / nice to have fix in it! There has been discussions with the developers that each change in the patch level release should have own change log entry as well. If change doesn't need change log entry then it doesn't belong to patch level release at all ;) Please make sure all issues blocking the Qt 5.4.1 release are linked to blocker meta bug: https://bugreports.qt-project.org/browse/QTBUG-43201 Also make sure all those are fixed early enough. We are already creating snapshots for 5.4.1 in http://download.qt.io/snapshots/qt/5.4/5.4.1/ for your testing verification purposes. br, Jani ___ Releasing mailing list releas...@qt-project.org http://lists.qt-project.org/mailman/listinfo/releasing ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
