> Hi, Hi,
> This is not quite a request for sponsorship, but rather something > like a request for help. The confget package, kindly sponsored by > George Danchev back in March, has remained in unstable since then > because of a FTBFS bug #526961 on the "mips" and "mipsel" architectures. > I tried to ask for help on the debian-mips list - > http://lists.debian.org/debian-mips/2009/05/msg00009.html - but got > no reply. > > As noted in both the bug log and my email to debian-mips, I strongly > suspect a bug lurking in the hardening-wrapper; it might turn out > that George Danchev was right in doubting whether the build should be > hardened by default. FWIW, I personally think the hardening wrapper > is a great idea, and I enable it by default in all my packages, but > still... :) I agree that hardening is a good idea, it just could be trickier sometimes, since they are less tested on certain architectures. > So, now for the actual RFH: could anybody with access to a Debian > unstable installation on the mips or mipsel architecture try to build > the confget-1.02-1 package as currently available in unstable? > http://ftp.de.debian.org/debian/pool/main/c/confget/confget_1.02-1.dsc > If the build fails as in the buildd logs, could you please try my > new version at mentors.d.n: > http://mentors.debian.net/debian/pool/main/c/confget/confget_1.02-2.dsc > It is pretty much the same as 1.02-1, with the hardening wrapper > disabled, groff used instead of groff-base, and a couple of minor > fixups to the Debian packaging that should not affect the build or > the test suite. > > If the version without the hardening should build successfully, > just let me know and I'll upload a new one with the bug closed in > the changelog entry. Otherwise... I'll just have to start thinking > about what really causes the test failure :) > > Thanks in advance for any assistance! That smells like a bug in the compiler which failed to produce correct code on these architectures with hardening options enabled. As I see it, all tests failed at the same line in confget.c, so I guess we should be able to narrow that down and reassign #526961 against gcc. Meanwhile, we can upload confget_1.02-2 without closing #526961 with it. Agreed? -- pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
