[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Help needed with FTBFS bug 267413 - buildd problem?



Hi,

Very short version: 

Is it possible that a buildd keeps debconf information of uninstalled
build-dependencies?

Long version:

I am kind of puzzled about http://bugs.debian.org/267413. zope_2.6.4-1.2
has failed to build on ia64, sparc, mips, m86k, powerpc: On nearly every
architecture tried, except s390, and i386 for which the Uploader built
the package. This points to a problem that is not really architecture-
specific, doesn't it?

The actual error message is 

debiandoc2ps debian/doc/zope-policy.sgml
debiandoc2ps: ERROR: zope-policy.ps could not be generated properly
debiandoc2ps: rerun with the -v option to found out why
make: *** [zope-policy.ps] Error 1

This doesn't tell much without the output that "-v" would give,
therefore, I tried to reproduce it, but essentially I failed. Those
attempts uncovered a different bug, giving the same error message, also
discussed in this bug log. 

But this cannot, or should not, be the cause of failure on a buildd, and
if this other problem is fixed, I cannot reproduce it; it builds fine
here on i386 as well as on merulo (ia64).

I also had the idea that it might be connected with some special setup
in the buildd's, and set up a sbuild chroot locally (i386): Still not
reproducable, zope builds fine.

So I don't really have an idea what the reason might be, and how to
proceed. The only little thing is that other bug, which I think cannot
(or should not) occur on a buildd.


This other bug is that tetex-bin has switched some debconf defaults from
false to true, without catering for the change in config or
postinst. This has the effect that on machines kept up-to-date in sid or
sarge with noninteractive updates (or hit-RETURN-always), the old
defaults are still in effect. But, and that is what makes it a real bug,
tetex-bin now relies on the new defaults, otherwise it will fail to
operate under some circumstances. Installation will work, however.

Well, of course "debiandoc2ps *.sgml" is one of those circumstances,
giving the error message described above. BUT: On a buildd this bug
should never be triggered, because each time a build-dependency (like
tetex-bin) is installed, it is also purged again: purged, not
uninstalled. 

- Is there any possibility that debconf answers are conserved between
  build attempts?

- Is there any way to have one of the failing buildds execute
  "debiandoc2ps -v some.sgml" without uploading a package just for that? 

Many thanks in advance,
Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie



Reply to: