No backport is contemplated. Backporting Qt breaks too many applications.
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to qt4-x11 in Ubuntu.
https://bugs.launchpad.net/bugs/664431
Title:
Qt on armel is built with NEON by default
--
kubun
Am Dienstag, den 30.11.2010, 14:24 + schrieb Scott Kitterman:
> I understand it's a regression for some hardware from Lucid. This SRU is a
> regression for a different set of hardware. That's mitigated by the PPA
> packages that are being provided, but I think it's a reasonably novel
> int
I understand it's a regression for some hardware from Lucid. This SRU is a
regression for a different set of hardware. That's mitigated by the PPA
packages that are being provided, but I think it's a reasonably novel
interpretation of our SRU policy to tell users that had reasonably working
h
On Tue, Nov 30, 2010 at 11:15 AM, Scott Kitterman wrote:
> This is going to hurt users of neon capable systems (which is almost
> everyone). I don't think this SRU is consistent with Ubuntu policy.
It is going to hurt users of neon capable systems, and it's a post
release regression, that's why w
On Tue, Nov 30, 2010 at 11:58 AM, Oliver Grawert wrote:
>> 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
>> maint
> 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.
Scott Kitterman [2010-11-30 13:15 -]:
> I don't think this SRU is consistent with Ubuntu policy.
I accepted it under the premise that it is a regression from lucid
(read: all Qt applications crash right away with a SIGILL). It
happens on a dove board I have laying around, but I don't know how
This is going to hurt users of neon capable systems (which is almost
everyone). I don't think this SRU is consistent with Ubuntu policy.
--
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 Ubuntu
Bugs,
On Fri, Nov 19, 2010 at 2:44 PM, Ricardo Salveti wrote:
> I'll make a public PPA available with the neon compatible Qt, so people
> can continue using the released version with neon accelerated pieces.
Qt PPA with NEON enabled: https://launchpad.net/~rsalveti/+archive/qt-
neon
Please test and le
Em Terça-feira 09 Novembro 2010, às 10:27:16, você escreveu:
> See the -mfpu=neon there.
>
> I think I see the problem. It's upstream.
Upstream report created:
http://bugreports.qt.nokia.com/browse/QTBUG-15150
--
Thiago Macieira - thiago.macieira (AT) nokia.com
Senior Product Manager - Nokia,
Em Segunda-feira 08 Novembro 2010, às 19:40:34, você escreveu:
> One example:
> g++ -c -include .pch/release-shared/QtCore -g -O2
> -I/usr/include/freetype2 -pthread -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -mfpu=neon -O2 -fvisibility=hidden
> -fvisibility-inlines-hidden -Wall -W -D_RE
On Mon, Nov 8, 2010 at 2:09 PM, Thiago Macieira
<664...@bugs.launchpad.net> wrote:
> Em Segunda-feira 08 Novembro 2010, às 16:50:52, você escreveu:
>> testing the packages from ricardos PPA on a non NEON architecture
>> results in a SIGILL again :(
>
> Can you post a backtrace? It would be useful i
Em Segunda-feira 08 Novembro 2010, às 16:50:52, você escreveu:
> testing the packages from ricardos PPA on a non NEON architecture
> results in a SIGILL again :(
Can you post a backtrace? It would be useful if the build used -fno-inline, or
this will get a bit tricky to track down.
Please also v
On Friday, 29 de October de 2010 07:22:28 you wrote:
> if i read that code right it enforces NEON use if it cant open
> /proc/self/auxv ... sorry, but thats not acceptable, it should use a
> conservative default instead, can that be changed ?
Yes, I think it's a good idea.
--
Thiago Macieira - th
On Thursday, 28 de October de 2010 07:55:34 you wrote:
> I currently can't get the git code (download at 8k/s), so I checked
> the 4.7.0 release tarball and this commit doesn't seems to be
> included:
> """
> $ vim qt-everywhere-opensource-src-4.7.0/src/corelib/tools/qsimd.cpp
> ---
> #elif defined
On Thu, Oct 28, 2010 at 9:09 AM, Thiago Macieira wrote:
> This is the actual commit that introduces runtime verification of processor
> features on ARM:
> http://qt.gitorious.org/qt/qt/commit/5070c3ae331faf18f6997535356853cc61ef0ad7
>
> It was introduced before Qt 4.7.0rc1 so the Ubuntu build sh
On 27.10.2010 01:58, Scott Kitterman wrote:
>
> "Steve Langasek" wrote:
>
>> it is a performance regression on some hardware, in exchange for
>> correcting a regression in basic functionality of the package on other
>> supported hardware. In the absence of other solutions, I think this is
>> pref
"Steve Langasek" wrote:
>it is a performance regression on some hardware, in exchange for
>correcting a regression in basic functionality of the package on other
>supported hardware. In the absence of other solutions, I think this is
>preferable over the status quo. Do you disagree?
I believe
My understanding is it's fixed in 4.7.1 so it should be manageable for
someone to dig the proper fix out of Qt got.
--
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
19 matches
Mail list logo
