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-sparc-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: Qt5 switching qreal from float to double on arm*
On Thursday 07 November 2013 18:18:18 you wrote: 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. Thank you too for replying :) 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. Don't forget we are talking about *just* Qt5 here, *not* Qt4. We only have 3 apps building against Qt5 right now. If apps switch to Qt5 they will surely find some bumps, so this can be managed. * what about arm64? sounds like this one should be double from the start; not sure what it is right now I have not added any provisions to arm64, so with the next 5.2.0 [rc/final] upload it will switch to double. We are still on time if something needs a fix here. * 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 Now this *will* be messy. I have asked upstream [0] and so far haven't got any explicit reply from other distro's maintainers. [0] http://lists.qt-project.org/pipermail/development/2013-November/014017.html But, according to [1]: I should also point out that this option now allows selecting qreal to be float on other platforms, besides ARM. That's why I'm still spamming debian-ports ;) [1] http://lists.qt-project.org/pipermail/development/2013-November/014017.html So: - We don't know yet what other distros are going to do. - If we decide to do the change in Qt5, it will be *without* soname bump. Yes, I know many of you will think of this as **ugly**, but so far means 3 binNMUs per arch. Now if this is not acceptable, then no change will be made, because I won't change Qt5's SONAME. * 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 I really don't know, it was already there when I started using Qt back in Qt3's final days ;-) But I *do* know that if people want it gone, they will need to wait until Qt6 and provide the necessary patches :-/ Hope that helps, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
On Thursday 07 November 2013 18:55:31 Loïc Minier wrote: On Thu, Nov 07, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: - We don't know yet what other distros are going to do. IMO we shouldn't have distro-specific patching for this kind of stuff; it seems to commonly impact apps (which should be using qreal instead of assuming qreal is double) way too commonly, and we want binaries to be compatible between distros, so diverging from upstream seems a really bad idea. The problem is the can of worms it has been opened: now we have the *chance* to choose, so ideally we need maintainers from most distros cooperating to keep SONAME and ABI the same. Let's hope maintainers from other distros stand up. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
On Thu, Nov 07, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: - We don't know yet what other distros are going to do. IMO we shouldn't have distro-specific patching for this kind of stuff; it seems to commonly impact apps (which should be using qreal instead of assuming qreal is double) way too commonly, and we want binaries to be compatible between distros, so diverging from upstream seems a really bad idea. - If we decide to do the change in Qt5, it will be *without* soname bump. Yes, I know many of you will think of this as **ugly**, but so far means 3 binNMUs per arch. Now if this is not acceptable, then no change will be made, because I won't change Qt5's SONAME. Well, it's kind of ugly but we could take this hit once and go through a binary transition with a package name change, or some kind of other transition trick. Not pretty and breaks compat between binaries built against old lib and new lib, but things in Debian will be ok. Also, as you note, not too many things are using Qt5 yet; might be a good time to get this right. Likely something the release team would be able to advise on, I would guess. I really don't know, it was already there when I started using Qt back in Qt3's final days ;-) Eh ok; if you get the chance to ask, that would be helpful to know when porting apps; perhaps it's something to bring up upstream in issues faced by distros kind of chatters :-) -- Loïc Minier -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131107175531.ga25...@bee.dooz.org
Re: Bits from the Release Team (Jessie freeze info)
Am 29.10.2013 17:48, schrieb Ian Jackson: (Mind you, I have my doubts about a process which counts people promising to do work - it sets up some rather unfortunate incentives. I guess it's easier to judge and more prospective than a process which attempts to gauge whether the work has been done well enough.) As an example I remember having received several complains from e.g. the GCC maintainers in regards to the state of gcc on various ports[1]. Here I would suspect a patch would be sufficient without needing to actually NMU gcc to get the fix in. There are also stuff like the port concerns from DSA that attention. Right. that's not enough. GCC has some primary and some secondary release architectures. Toolchain support for primary architectures in Debian should be waived, for the secondary and other architectures, Debian needs somebody who is maintaining the relationship between Debian and upstream. Surprisingly this is the case for many non-release Debian architectures like kfreebsd, the Hurd, alpha, hppa, m68k, but not for Debian release architectures like s390, sparc, ia64 and mips*. So we really need somebody to care about this, where the port is considered a secondary citizen or no citizen, or we should demote a port to the ports archive. Matthias -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527c2170.8020...@debian.org
