Re: [Stretch] Status for architecture qualification
On 05/06/16 13:00, Holger Levsen wrote: On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote: ppc64: This architecture is basically on par with the release architectures. We have over 11.000 packages installed [...] sparc64: We are close to 11.000 installed packages. I'm not sure whether you are talking about source or binary packages but sid/amd64 has over 24000 source packages and over 5 binary packages, so I would call the above "on par". Or what am I missing? I presume he is talking about source packages in the "installed" state in wana-build. For comparison this is currently 12153 for amd64 and 10937 for mips. (this leads to the interesting conclusion that about half the source packages in sid are arch-all only)
Re: gnutls28 transition
Dimitri John Ledkov wrote: Hello all, gmp has been recently re-licensed and all architectures and ports have the updated gmp in jessie/sid. Well, all but powerpcspe x32 both of which recently have negative slope on their build status graphs. Thus GPLv2 and LGPLv3 compatible software packages can link against gnutls28. Should we start transition to gnutls28 by default, for all packages that are compatible? Can powerpcspe x32 porters try to get latest gmp built? Personally I'd add a (build-)depends on the relicensed gmp in the next gnutls28 upload. That way packages can (build-)depend on the new gnutls and be assured of getting a GPLv2 compatible version. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53659469.8060...@p10link.net
Re: Qt5 switching qreal from float to double on arm*
Lisandro Damián Nicanor Pérez Meyer wrote: Any feedback will be kindly appreciated. I've always thought there is something fundamentally wrong. What is qreal supposed to be used for? If it's supposed to be used for things where float would be adequate then shouldn't it be float on all platforms? If it's supposed to be used for things where float is inadequate then why isn't it double on all platforms? The current situation leads to people who develop on i386 and amd64 (which is most developers) assuming that qreal is equivilent to double. Then we try and build it on arm* and float gets used. Sometimes this is ok because there was really no reason for the developer to be using double precision in the first place and there were no incorrect conversion assumptions. Sometimes this causes build failures which can be difficult to resolve* and I bet in some cases it causes more subtule bugs. It also goes against the principle of offering to the greatest extent possible the same functionality on all platforms. Making qreal double on armhf but leaving it as float on armel will mean that canonical are no longer forced for fix bugs surrounding it. I'm sure canonical would like that but I also suspect it may cause severe degredation in the maintainance of QT software on those ports that stick with qreal. On the other hand presumablly there would be a performance hit from switching from float to double, especially on platforms which use software floating point (I presume that was why whoever controlled qt at the time made qreal float on arm in the first place). I found some older upstream discussion on what to do about float at https://groups.google.com/forum/#!topic/qt-project-list-development/dPcP3NASY1k I also found some discussion at http://comments.gmane.org/gmane.comp.lib.qt.qt5-feedback/700 saying that on coretex A8 double was significantly slower than float. Finally has there been any discussion with other linux distros. This is obviously something that impacts the ABI in a big way so ideally it's not something where we want different distros doing different things. * See scribus for an especially nasty example. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52758a05.9090...@p10link.net
Re: Bits from the Release Team (Jessie freeze info)
Johannes Schauer wrote: Until these two issues are fixed we will not be able to get an algorithmic answer to the question of what constitutes the minimum required set of packages. There is also the complication of what I will call non-key self building compilers. fpc is an example These are not needed to bootstrap the core of debian but if one wants to bootstrap all of debian they will need to be built. Since the only way to build them is with themselves they cannot be bootstrapped natively even with the help of build profiles. So the only way to bootstrap them is to either cross-build them or start with a binary from upstream. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526c4c1c.3060...@p10link.net
Re: changing the java default to java7, and dropping java support for some architectures
:-) I'm one who asked there some time back why java7 is no longer in the archives (unstable/experimental), while the last binaries I had installed still work OK on my mini-pc... I'm just curious, sorry for asking to the lists... I want to understand if the mini-pc is still a low performance desktop alternative with java enabled, or is no longer suited for that, :-) So your answers are very appreciated. The problem is that if you want openjdk on your architecture then someone has to commit to doing the work to keep it building and working in the face of changes from upstream. For x86/x64 and presumablly to some extent sparc (though I don't know if they test linux/sparc or only solaris/sparc) upstream keeps it working. For arm ubuntu and probablly other commerical linux distros need to keep it working. Powerpc seems to be be getting at least some support from IBM. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/519eb6e6.1020...@p10link.net
