On Sat, Apr 05, 2008 at 01:39:00PM +0200, Jörg Sommer wrote: >Hallo Steve,
Hi Jörg,
>Steve McIntyre schrieb am Sun 23. Mar, 19:51 (+0000):
>> Package: slrn
>> Version: 0.9.9~pre97-1
>> Severity: serious
>>
>> On the mips buildd "ball", slrn builds correctly, but the debian/rules
>> file does a check on the output binary objects to see if the hostname
>> is encoded anywhere.
>
>We are talking about the *FQDN*. The check uses hostname -f.
It's not uncommon that various machine configurations (e.g. chroots,
vservers) may leave the domain bits of the FQDN empty. Also, as I
mentioned to people on IRC late last night, valid FQDNs may match too:
00:51 < Sledge> zobel / bzed: it's entirely possible to have a valid
FQDN that will break the slrn build
00:51 < Sledge> imagine "mat.is", which I've just looked up and it
exists
>Because slrn has still the option to hard-code the domain name, I treat
>this check as useful. I don't see why it's okay if the hostname of the
>build machine is hard-coded in the binary.
Oh, I agree on that completely. I don't agree that that justifies
using a test that's too fragile and likely to break. What happens if
(by chance) random optimisations in a newer version of gcc happen to
cause strings in the binary to match the FQDN? Should that cause the
build to fail too?
>If you still think it's a bug in slrn, explain why it's okay to find the
>*FQDN* (not only the hostname ball) in the binary. Otherwise I mark this
>bug as wontfix.
I don't care about this particular case (ball), that's not the
point. I'm pointing at a more general problem that could cause future
random build failures, both on buildds and for users. Do you
understand where I'm coming from?
--
Steve McIntyre, Cambridge, UK. [EMAIL PROTECTED]
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/
signature.asc
Description: Digital signature
