Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 2013-10-29 17:48, Ian Jackson wrote: Niels Thykier writes (Re: Bits from the Release Team (Jessie freeze info)): [...] As mentioned we are debating whether the 5 DDs requirement still makes sense. Would you say that we should abolish the requirement for DD porters completely? I.e. Even if there are no (soon to be) DDs, we should consider the porter requirements fulfilled as long as they are enough active porters behind the port[0]? I don't have a good feel for the answer to that question. It's just that if it is the case that a problem with ports is the lack of specifically DDs, rather than porter effort in general, then sponsorship is an obvious way to solve that problem. If you feel that that's not really the main problem then a criterion which counts porters of any status would be better. I suppose a sponsor-only DD could be sufficient, provided that the sponsor knows the porters well enough to be willing to sign off on e.g. access to porter boxes. I guess the sponsor would also need to dedicate time to mentor (new?) porters on workflows and on quicks like when is a FTBFS RC and when it isn't etc. (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.) [...] Thanks, Ian. Ah, you are not the first to question this process. Obviously, we intend to keep people up on their promise by actively maintaining their port. Sadly, we do not have a clear definition of actively maintained ports and I doubt we will have it any time soon either. But porters can start by working on the concerns from DSA (if they haven't already done so). Ports having gcc-4.6 as default compiler might also consider improving in that area[1]. Then there are more concrete things like ruby's test suite seg. faulting on ia64 (#593141), ld seg. faulting with --as-needed on ia64 (#718047[2]), a lot of ruby packages being stuck on kfreebsd-any due to ruby2.0 FTBFS (#726095[3]). Personally, I would also expect that key-packages work on all ports (on which they are built) in general[4]. All of the (non-mild) DSA concerns are already something we will officially hold against the ports. Most of the other issues listed above are not official concerns. However, I would not be surprised if most of them became official issues eventually. Until we have a clear definition of actively maintained ports, I would recommend porters to err on the side of being verbose over being silent. As an example, lack of visible reply to mails like [5] makes it seem like nobody is home. Mind you, I am not saying porters have the responsibility to fix every problem forwarded to their port list. I am also aware that sometimes issues/mail disappear in the depths of people inbox - heck it happens to me as well. Come to think of it; maybe we should have a BTS page for each of the ports (e.g. a pseudo package in the BTS). That way it would at least be easier for all people to find outstanding issues for the port[6]. It would also give us the possiblity to trivial declare a problem RC (or not) for ports. (Plus, then I won't have to update some random file on release.d.o for every new issue :P) Anyhow, I hope to be able to give a more official statement in the near future. ~Niels [1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be acceptable as a default for Jessie. [2] Apparently it is controversial whether that bug should be RC, but it definitely looks like that kind of thing that will cause issues for ia64 later. [3] That one got a patch, but it might be worth it to put some pressure on the maintainer or even doing a NMU. [4] A rule of thumb could be something like your port should probably not be listed here in the long run: http://udd.debian.org/bugs.cgi?release=jessie_and_sidmerged=ignkeypackages=onlyfnewerval=7flastmodval=7rc=1sortby=idsorto=asc [5] https://lists.debian.org/debian-mips/2013/08/msg5.html Btw, this is not intended to single out mips. [6] I know that people have been usertags for issues that affect the port, but it is not clear to me that all those usertags bugged is something we expect porters to fix. Rather it seems more like porters tagging the FTBFS bugs they file. -- 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/52762b6a.5060...@thykier.net
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
Niels Thykier dixit: Then there are more concrete things like ruby's test suite seg. faulting on ia64 (#593141), ld seg. faulting with --as-needed on ia64 And only statically linked klibc-compiled executables work on IA64, not dynamically linked ones. I’ve looked into it, but Itanic is so massively foreign I didn’t manage to find out anything except that the problem appears to happen before main. Until we have a clear definition of actively maintained ports, I would recommend porters to err on the side of being verbose over being silent. I’ve held off on the m68k side because I think the role call was only for architectures in the main archive, right? [1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be acceptable as a default for Jessie. Didn't Doko say he’d want 4.8? We (on the m68k side) are putting effort into that one, since 4.7 appears to only be used by eglibc right now. And 4.6 for GNAT, but gnat-4.8 is new, and the ICE may be fixed as there’s active upstream on the GCC/m68k side. bye, //mirabilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- 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/pine.bsm.4.64l.1311031444380.31...@herc.mirbsd.org
Re: Potential issues for most ports
On 2013-11-03 15:49, Thorsten Glaser wrote: Niels Thykier dixit: [...] Until we have a clear definition of actively maintained ports, I would recommend porters to err on the side of being verbose over being silent. I’ve held off on the m68k side because I think the role call was only for architectures in the main archive, right? Yes, we are only talking about architectures in the main architecture. [1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be acceptable as a default for Jessie. Didn't Doko say he’d want 4.8? We (on the m68k side) are putting effort into that one, since 4.7 appears to only be used by eglibc right now. And 4.6 for GNAT, but gnat-4.8 is new, and the ICE may be fixed as there’s active upstream on the GCC/m68k side. bye, //mirabilos I am not entirely up to speed on what he wants; I am still waiting for him to get back to me (see [1]). ~Niels [1] https://lists.debian.org/debian-release/2013/10/msg00710.html -- 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/527671af.7050...@thykier.net
Re: Potential issues for most ports
On 2013-11-03 16:54, Niels Thykier wrote: On 2013-11-03 15:49, Thorsten Glaser wrote: Niels Thykier dixit: [...] Until we have a clear definition of actively maintained ports, I would recommend porters to err on the side of being verbose over being silent. I’ve held off on the m68k side because I think the role call was only for architectures in the main archive, right? Yes, we are only talking about architectures in the main architecture. s/main arcihtecture/main archive/; ~Niels -- 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/527674bd.2070...@thykier.net
Re: Qt5 switching qreal from float to double on arm*
Note: adding back debian-arm@..., please tell me if it's not necessary. On Saturday 02 November 2013 23:25:57 peter green wrote: 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. Peter: I'm not in the position of changing qreal's existence, so I'm not here to argue if qreal is a good idea or not. The important thing is that qreal has been in Qt since at least Qt3, and, as far as I remember, has always been defined to be double on archs that natively support it and float on those that didn't. 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. I really don't understand where Canonical gets in here. I don't work for Canonical nor I am an Ubuntu maintainer .Qt5's change comes from Lars Knoll, the current main/lead architect of the project. And we are still left with the possibility to define what value will qreal take (see below). I also don't understand what you mean with ports that stick with qreal. qreal is a typedef which type is defined at compile time. Did you meant float? 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). That's why they added an option to bypass this at compile time (see my previous mail) and also the main reason that I left armel as float. Of course, it might be that some armhf's hardware isn't capable of doing double, which is not what I currently understand, but feel free to correct me. But the most important thing here is that if the porters decide that we better stick to float for qreal, I have no problem in doing so. I found some older upstream discussion on what to do about float at https://groups.google.com/forum/#!topic/qt-project-list-development/dPcP3NAS Y1k 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. I have not participated in any way in upstream's decision nor I have the power to overcome them. Anyway, we are giving the choice of a compile-time parameter to better suit our needs on purpose. Kinds regards, Lisandro. -- 18: Como se pueden evitar los problemas de alimentacion electrica * No coma cerca de un enchufe Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html 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: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Sun, Nov 03, 2013 at 11:54:34AM +0100, Niels Thykier wrote: On 2013-10-29 17:48, Ian Jackson wrote: Niels Thykier writes (Re: Bits from the Release Team (Jessie freeze info)): [...] As mentioned we are debating whether the 5 DDs requirement still makes sense. Would you say that we should abolish the requirement for DD porters completely? I.e. Even if there are no (soon to be) DDs, we should consider the porter requirements fulfilled as long as they are enough active porters behind the port[0]? I don't have a good feel for the answer to that question. It's just that if it is the case that a problem with ports is the lack of specifically DDs, rather than porter effort in general, then sponsorship is an obvious way to solve that problem. If you feel that that's not really the main problem then a criterion which counts porters of any status would be better. I suppose a sponsor-only DD could be sufficient, provided that the sponsor knows the porters well enough to be willing to sign off on e.g. access to porter boxes. I guess the sponsor would also need to dedicate time to mentor (new?) porters on workflows and on quicks like when is a FTBFS RC and when it isn't etc. Why would the sponsor need to be involved in getting the porters access to porter boxes? Porter boxes exist so that DDs *not* involved in a port have access to a machine of the architecture and can keep their packages working. I've never heard of a porter who didn't have access to their own box for porting work. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
