Re: Qt5 switching qreal from float to double on arm*

On Saturday 09 November 2013 10:22:44 Philipp Kern wrote: What is your plan to support partial upgrades? BinNMUs can require new Qt versions to be installed, but Qt can be upgraded independently to the newer version, causing the rdepends to crash. This can potentially be solved by Breaks, but

Re: Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

On 2014-02-17, Steve McIntyre st...@einval.com wrote: Yes, you can do that - build several copies of the library and use the hwcaps / auxv approach to pick the best one for the hardware at link time. NEON detection may come... but if we have linker selection, that would be covered right now.

kde4 on debian arm armel

Hi peoples! kde4 release candidates are in experimental. The experimental arm buildd seems to fail to build with some weild errors from libstdc++ CMakeFiles/kdecore.dir/io/kmessage.o: In function `internalMessageFallback': /build/buildd/kde4libs-3.97.0/kdecore/io/kmessage.cpp:81: undefined

Re: kde4 on debian arm armel

On 2007-12-19, Martin Guy [EMAIL PROTECTED] wrote: 2007/12/19, Sune Vuorela [EMAIL PROTECTED]: kde4 release candidates are in experimental. The experimental arm buildd seems to fail to build with some weild errors from libstdc++ If someone with a bit more clue than me could try look

Re: armelfp: new architecture name for an armel variant

On 2010-07-06, Brian Szymanski skibrian...@gmail.com wrote: Suggested arch names: armfast / armfull ? to later be superceded by armfaster, armsuperfast, armmegafast ? /Sune -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

failed kde-related packages

Hi! At least the following kde related packages are marked as failed because of uninstallable build-deps on kdelibs-dev or kdebase-dev. Both should be installable by now. Can you please reschedule some of them? kalgebra kmldonkey kwin-style-crystal strigiapplet klibido ksynaptic kwave and

Re: Summary of the ARM ports BoF at DC16

On 2016-07-22, Steve McIntyre wrote: > is the lack of direct support for C++11 atomics - it's possible to use > a kernel helper to cover for this lack, but performance will be > terrible. This is going to be a real problem for Qt in the very near future. A requirement for qt

Re: Anyone using stretch/buster/sid on ARMv4t ?

On 2017-11-07, Adrian Bunk wrote: > This whole "so many packages are broken on armel" narrative > is actually mostly FUD, and you are suggesting mitigations > for a nonexisting problem. Have we gotten full c++11 support on armel yet ? (future, atomic, ...) /Sune

Re: Upcoming Qt switch to OpenGL ES on arm64

On 2018-11-23, Julien Cristau wrote: > Why is it OK to break them on arm64 if it's not OK to break them on > amd64? Do you have a list of those packages? Because most people on arm64 don't have the hardware. Rather give them fewer packages that works great rather than many packages that

Re: Upcoming Qt switch to OpenGL ES on arm64

On 2018-11-24, Andy Simpkins wrote: > BOTH are possible so why dictate only one? Because it would require two flavours of all users. /Sune

Re: another attempt at Y2038

On 2022-10-18, Arnd Bergmann wrote: > Just for my understanding: what would be the correct way to handle this, > under the assumption that the new symbol names that dpkg-shlibdeps > found are the ones we want? Is there a way to flag both the time32 > and the tim64 set of symbols as correct, or