Re: RFH, AlmostRFS: confget-1.02-2 (updated package)
> 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>
Reply to: