Re: Qt5 switching qreal from float to double on arm*
On Sat, Nov 02, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not from beta1 currently in experimental) Qt5 will switch qreal from float to double on arm*. We have the option to keep some archs in float by passing a compilation parameter. I've done so for armel and sh4, so only armhf will switch to double. Of course we are still on time to discuss this, and this is the reason of this mail. What do you think WRT the above changes? First, thanks a lot for the heads up on this. qreal being float instead of double on ARM was the source of a bunch of work for ARM porters in the past; now I have these worries/questions: * switching it back might imply some new porting work (in the case where the patches were something #if ARM use float #else use double); this might be particularly painful if armel and armhf have different definitions. Maybe there's a nice define #QREAL_IS_FLOAT or something to help with this. * what about arm64? sounds like this one should be double from the start; not sure what it is right now * when you say you've changed armel and sh4 to keep using float, is this Debian-specific? Not sure we want a delta with upstream on this kind of stuff. Would it not work at all to use double, or would it just be slow? I'd rather have it slow for people using big software on slow arches rather than keeping a delta; it sounds like we do a SONAME transition no matter what anyway * what's the point in qreal anyway? can't we just switch everything to float or double? sounds like software should know what kind of level of precision it needs in the first place; e.g. if it's a scale in some UI, then either float or double is enough, but it's not an arch specific decision Thanks again for raising this! -- Loïc Minier -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131107171818.gb12...@bee.dooz.org
Re: Bug#405012: libwmf: Dependencies problem on experimental
On Sat, Jan 27, 2007, Vitezslav Kotrla wrote: I've noticed new i386 package in experimental, thanks a lot. Is it possible to provide amd64 package, too? I don't have an amd64 and the amd64 buildd is probably not able to autobuild libwmf in experimental with its current software, so you'll have to wait until someone uploads a binary build or the software is fixed. dpkg (subprocess): unable to execute old post-removal script: Exec format error This is weird, did you use a chroot for building? It looks like mixed architectures to me. Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Unable to resolve addresses only with some tools
[ Please Cc: me, I'm not on [EMAIL PROTECTED] ] On Fri, Jan 12, 2007, Pascal Giard wrote: I solved my problem by reinstalling libnss-mdns_0.8-6.1_amd64.deb !! How come I was able to uninstall it without being notified that it was crucial?! Versions 0.8-6 and 0.8-6.1 (my first NMU of the package) did not remove the entries for mdns of nsswitch.conf. I knew this fact when I uploaded the NMU but did not address it as the maintainer of the package had described this fact explicitely in README.Debian which explained this would result in an unnoticable delay; from 0.8-6/nss-mdns-0.8/debian/README.Debian: Note: this is never removed once installed, the side-effect of not removing the entry is that there is a slight delay (similiar to how the Standard C libraries searches for optimised versions) during program startup and execution It turned out to cause problems to leave this entries, and I re-added a postrm snippet based on work by Joey Hess in his 0.8-4.2 NMU of the package. I've re-added the removal in my second NMU, 0.9-0.1. You probably removed the package in version 0.8-6.1, if you upgrade and remove it in version 0.9-0.1, it should not cause the side effects you noticed. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
