Re: [Development] Adding new third party component three.js to Qt?
On Wednesday 14 January 2015 09:24:43 Thiago Macieira wrote: On Wednesday 14 January 2015 11:38:55 Lisandro Damián Nicanor Pérez Meyer wrote: The same can be said about C/C++ 3rdparty libraries. So no, bundling is not good for distros. Imagine a security bug appears: we need to start hunting down each embedded version and fix it, checking that we don't break anything specially in forked cases. A nightmare. Actually, the problem here is not that of shipping a bundled version. It's embedding the binary inside one of Qt binaries. Let's solve this problem first: how to find the JS file (minified or not) somewhere on disk, without Qt resources. Once that is solved, distros can opt to build three.js from the official sources and apply the necessary Qt patches in the manner that is most helpful to them. This would indeed be a nice way to start fixing this. I might be becoming mad, but I'll see what can be done in that regard (we do have a policy for that, but so far Debian-only as far as I know). -- 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] Adding new third party component three.js to Qt?
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. 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. 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? 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. 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. 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). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding new third party component three.js to Qt?
Lisandro Damián Nicanor Pérez Meyer wrote: That might be a question for Kevin, but on Debian a javascript library is treated as any other C/C++ library: source code should be there, the binary/minified version must be created from the unminified code at package build time (ie, when building the source code that ships it). It doesn't matter what uses it. That is also true in Fedora. What we do not have guidelines for so far is reuse of systemwide JavaScript libraries in non-web applications. So Qt will probably get away with bundling three.js for now. But shipping it only in minified form is also banned by global Fedora policies and thus clearly unacceptable. My recommendation is to not ship a minified file in the source tarball at all (we would have to remove it), but to generate it at build time. However, please make sure the minifier you are using is Free Software. The popular JSMin is NOT Free Software: http://wonko.com/post/jsmin-isnt-welcome-on-google-code http://www.gnu.org/licenses/license-list.html#JSON and therefore NOT an acceptable build dependency for Qt (or any other package for that matter) in Fedora and Debian: https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses (JSON License) https://bugzilla.redhat.com/show_bug.cgi?id=455507 https://wiki.debian.org/qa.debian.org/jsonevil So please use UglifyJS or another acceptably-licensed minifier instead. Kevin Kofler ___ 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 17:48:16 Thiago Macieira wrote: On Friday 16 January 2015 01:38:50 Kevin Kofler wrote: What we do not have guidelines for so far is reuse of systemwide JavaScript libraries in non-web applications. So Qt will probably get away with bundling three.js for now. But shipping it only in minified form is also banned by global Fedora policies and thus clearly unacceptable. To clarify: minified-only is obviously bad. But what if we ship source and the generated minified files? We (Debian) need to remove the minified sources from the original tarball. 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 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. 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. There are exceptions with stuff that can be used on all archs (like docs, called arch: all in Debian's jargon) but those are probably going to dissapear once arch:all packages are built on Debian's infra. 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. If that's ok, does it matter that a non-free tool was used? I'm guessing it does matter, even if there's a free one can also produce a valid output. Yes it does matters, totally. Requiring a non-free tool to build would make Qt and **everything** that depends on it to the contrib repo: free software stuff that needs non-free stuff to build and/or run. And that supposing we can ship the build tool in non-free, else we would simply not be allowed to build that part. 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). As a side note, Debian's rules are also Ubuntu's ones for most of their stuff, including Qt. -- 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] Adding new third party component three.js to Qt?
I think it's also good to notice that (once again, we in Debian) if a lib is shipped under 3rdparty but the build process auto detects a system one and uses it instead is definitely a nice solution for us. Yes, we maintainers need to check the code of the 3rdparty stuff and their licenses, but as long as we don't build it there is nothing wrong to have the code there. -- 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] Adding new third party component three.js to Qt?
On Friday 16 January 2015 01:38:50 Kevin Kofler wrote: What we do not have guidelines for so far is reuse of systemwide JavaScript libraries in non-web applications. So Qt will probably get away with bundling three.js for now. But shipping it only in minified form is also banned by global Fedora policies and thus clearly unacceptable. To clarify: minified-only is obviously bad. But what if we ship source and the generated minified files? 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. If that's ok, does it matter that a non-free tool was used? I'm guessing it does matter, even if there's a free one can also produce a valid output. -- 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
