I support entirely David's position: we committed to delivering an userspace not requiring NEON, independently from the binary kernels or the images directly in Ubuntu. This is true of both maverick and lucid.
The fact that the whole of Qt was built with NEON is a bug, and there is no doubt that we should fix this hard requirement of NEON in an important library. NEON will still be used at runtime, so not every optimization is lost. There are multiple ways to deal with the speed regression, in a second step: a) we could arrange for an armel PPA with a Qt rebuilt with NEON (this is true of any package BTW); this requires special permission, and ongoing maintenance, but Qt isn't updated frequently in stable releases. b) we could provide a new qt4-x11-neon source package + alternate binaries in maverick-updates c) we could change qt4-x11 to build two sets of libraries, albeit this would be considerably heavier in build time I think b) is not too intrusive if we drop the libs in lib/vfp/neon, we could even pull them in installed system via a Recommends from qt4-x11, albeit I do find this part intrusive, much more than a speed difference on ARM systems. -- QT on armel is built with NEON by default https://bugs.launchpad.net/bugs/664431 You received this bug notification because you are a member of Kubuntu Bugs, which is subscribed to qt4-x11 in ubuntu. -- kubuntu-bugs mailing list kubuntu-b...@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
