Bug#854609: swi-prolog: FTBFS on mips
Hi Sébastien, 11.02.2017 14:22, Sébastien Villemot пишет: > If swi-prolog is removed from stretch, then several reverse > dependencies will also go away (in particular sagemath and ppl > maintained by the Debian Science Team, which is what prompted me to fix > #852892). > > So I think you should not remove swi-prolog unless there is no other > option. Dropping swi-prolog-java on mips seems a reasonable fix for the > FTBFS on that arch. > > IMO, the only reason why you may want to drop swi-prolog from stretch > is if it is impossible to provide security support. If you are unsure > about this, you may want to contact the Debian Security Team. OK, I see your point. I'll drop swi-prolog-java on mips (for version 7.2.3). Cheers! Lev signature.asc Description: OpenPGP digital signature
Bug#854609: swi-prolog: FTBFS on mips
Dear Lev, On Wed, 08 Feb 2017 21:52:12 +0500 Lev Lamberov wrote: > So, there are simply two options: > > 1. Do not build swi-prolog-java on mips (as it already done on armel > and armhf), and let swi-prolog enter stretch. > > 2. Do not let 7.2.3 version of swi-prolog enter stretch. > > As for me I vote for the second option, because I don't think that it > is a good idea to let dead (= without upstream support and without > enough competent contributors in Debian, who is interested to keep it > alive) branch of some piece of software enter stable release and stay > there for 2 or more years. It simply will _not_ have any good support, > which I'd consider as a bad thing. > > My suggestion, as partly stated above, is to have that RC bug open to > not let swi-prolog enter stretch. But after stretch release 7.4 > (moreover 7.4 should have OpenSSL 1.1 support, which is absent in 7.2) > branch of swi-prolog will be ready and I'll upload it to backports. > > But if there are anyone who _really_ need swi-prolog in stretch, I'm > open to your suggestions and can manage with the first option. (In > this case, please, do not expect good level of support of swi-prolog > in stretch.) If swi-prolog is removed from stretch, then several reverse dependencies will also go away (in particular sagemath and ppl maintained by the Debian Science Team, which is what prompted me to fix #852892). So I think you should not remove swi-prolog unless there is no other option. Dropping swi-prolog-java on mips seems a reasonable fix for the FTBFS on that arch. IMO, the only reason why you may want to drop swi-prolog from stretch is if it is impossible to provide security support. If you are unsure about this, you may want to contact the Debian Security Team. Cheers, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://sebastien.villemot.name `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Bug#854609: swi-prolog: FTBFS on mips
Package: swi-prolog Version: 7.2.3+dfsg-5.1 Severity: serious Justification: FTBFS Hi, something broke swi-prolog in Debian (see #852892), but it revealed another problem. Java tests fail on mips with segmentation fault. Unfortunately, 7.2 branch of swi-prolog is almost at its end of life stage and it is not supported by upstream in an appropriate manner. Currently, upstream works heavily on releasing 7.4 branch (7.4-rc1 was released two weeks ago), which as upstream puts it will be supported by security fixes for a long time and in an appropriate manner. I've tried to play with build flags, but (unfortunately!) my attempts to fix the bug were unsuccessful. So, there are simply two options: 1. Do not build swi-prolog-java on mips (as it already done on armel and armhf), and let swi-prolog enter stretch. 2. Do not let 7.2.3 version of swi-prolog enter stretch. As for me I vote for the second option, because I don't think that it is a good idea to let dead (= without upstream support and without enough competent contributors in Debian, who is interested to keep it alive) branch of some piece of software enter stable release and stay there for 2 or more years. It simply will _not_ have any good support, which I'd consider as a bad thing. My suggestion, as partly stated above, is to have that RC bug open to not let swi-prolog enter stretch. But after stretch release 7.4 (moreover 7.4 should have OpenSSL 1.1 support, which is absent in 7.2) branch of swi-prolog will be ready and I'll upload it to backports. But if there are anyone who _really_ need swi-prolog in stretch, I'm open to your suggestions and can manage with the first option. (In this case, please, do not expect good level of support of swi-prolog in stretch.) Cheers, Lev Lamberov -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages swi-prolog depends on: ii swi-prolog-nox 7.2.3+dfsg-5.1 ii swi-prolog-x7.2.3+dfsg-5.1 swi-prolog recommends no packages. Versions of packages swi-prolog suggests: pn prolog-el -- no debconf information
