Launchpad itself

inn2 dependency causes build failure

Asked by Timothy Pearson

When trying to build a package dependent on inn2, I get a "innconfval: hostname does not resolve or domain not set in inn.conf" failure from the PPA builder and the installation process halts. Is there any way to get this fixed?

Interestingly, the AMD64 build succeeds, while the LPIA and i386 builds fail.

i386 Failure log is here: http://launchpadlibrarian.net/29532700/buildlog_ubuntu-jaunty-i386.smartcardauth_1.0-0ubuntu1_FAILEDTOBUILD.txt.gz

This is not an issue with my package from what I can see, but is instead a PPA builder configuration issue.

Thanks!

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
Celso Providelo Edit question
Solved by:
Timothy Pearson
Solved:
Last query:
Last reply:
Whiteboard:
Assign to cprov, at mrevell's suggestion and with cprov's agreement. -kfogel 2009-07-30

This question was reopened

Revision history for this message
Timothy Pearson (kb9vqf) said : 		#1

It was a builder issue, specifically with sandpaperfig and aluminum. Retrying the build until a different machine built the package fixed the problem.

Revision history for this message
Timothy Pearson (kb9vqf) said : 		#2

I would like to mention that this seems to fail on most builders; the only ones that work I suspect are the actual "master" machines that the other builders are running on top of. For example, iridium is the only i386 builder that works.

Is there a way to get this fixed?

Revision history for this message
Adam Conrad (adconrad) said : 		#3

There are no "master" machines, each one is separate. What's more interesting, though, is I can't find any particular differences between name resolution on sandpaperfig and mercury (the latter being one that worked, apparently).

It would be nice if someone could track down exactly what inn2 is doing here. In theory, it's "trying to resolve the FQDN of the machine", but in practice, if it's failing, it's doing something else entirely, since the postinst actually has a guard around starting inn2 for just this very case:

if hostname --fqdn > /dev/null 2>&1; then
    invoke-rc.d inn2 start || echo "Could not start INN!"
else
[...]

Beyond that, all I can really ask is "why on earth does any package build-depend on things like initramfs-tools and a news server", but whatever. Without knowing what it is that inn2 is choking on, I'm grasping at straws, and both these hosts have no problems looking up their own FQDN, which is supposedly what's failing.

Revision history for this message
Adam Conrad (adconrad) said : 		#4

Or, rather, it may be one of the earlier commands bombing out before starting inn2. Hrm. Either way, sandpaperfig can resolve its own FQDN fine so, either this issue was transient, or the issue isn't what inn2 claims it is...

Revision history for this message
Timothy Pearson (kb9vqf) said : 		#5

Thanks for the info on the build farm...I was guessing that since there were virtual builders, there might be a "master" machine which the others were running on. Now I know better! ;-)

The package in question needs the ckpasswd utility from inn2. If this problem continues to occur I'll rewrite ckpasswd and build it separately in my package.

Thanks again!