Qt 5.4 update (and call for testing), January 25
Dear Ubuntuers, Today we have reached a point when our Qt 5.4 packages are finally built on all architectures — so I decided to post a quick update on the current Qt 5.4 status. Disclaimer: we are still far from “ready for being uploaded to vivid archive” state. That will happen only when Qt 5.4.1 packages are ready and all blocking bugs are fixed. Recent progress === * All the initial Qt 5.4 packaging was done by Timo Jyrinki. * qtwebsockets tests failure has been fixed, thanks to Helge Deller. * stellarium and qtserialport build failures have been fixed, thanks to Łukasz Zemczak. * some touch-related packages have been rebuilt against Qt 5.4 (Dmitry Shachnev, Łukasz Zemczak). * some Qt packages have been synced/merged from Debian experimental (Dmitry Shachnev). Known bugs == The full list of Qt 5.4 bugs is available at https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt5.4. The most important bugs are: * qtbase tests failures * ubuntu-ui-toolkit tests failures * unity8 behaviour bugs Help with dealing with all these bugs is always welcome. Updating to Qt 5.4 == The Qt 5.4 packages are available in ppa:ci-train-ppa-service/landing-005. These packages are unstable and may break your system. That PPA is regularly synced with archive, so that all packages there are re-built against Qt 5.4. Upgrade instructions for both mobile devices and desktop are available at https://wiki.ubuntu.com/Touch/QtTesting. Please test these packages and report any bugs you find (tagged with ‘qt5.4’ tag). -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: openssl performance delta built-in vs custom compiled
Marcus Pollice On 22.12.2014 03:20, Mathieu Trudel-Lapierre wrote: I don't think there would be very many patches that are meant to improve performance in our patch set (note, I did not check). That was a good assumption. Although some patches looked suspicious I ultimately found that these patches don't materially affect performance. More about that below. You may also which to check what are all the compiler options coming from dpkg-buildflags used in the build... That was a good idea indeed, but there was nothing out of the order coming from there. Also since openssl writes the compile options to the console when running the benchmarks I could test most of these before to have no real effect. I would suggest using the source package as a base and using debuild / chroots / PPAs to build your custom package, that way you'd benefit from the same performance unless your custom changes impact them in some way, with the least amount of effort. Ultimately I used the Debian way of building to reproduce the same performance level as the built-in packages. Then I started playing with doing certain steps of the compilation manually vs automated building. When I got a build with the patches applied and the same low performance I was getting before I knew it was not the patches. I then dissected the buildlog and at some point I noticed the major difference is that the built-in version will be compiled with shared libraries. This is indeed the root cause for the performance difference I found. The versions using shared libraries are indeed faster than a static build (at least for the small data sizes). This is completely unexpected to me. It is also somewhat unsatisfying as I now know the cause but don't quite understand it. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
