On Mar 26, Hendrik Sattler ([EMAIL PROTECTED]) wrote:
 > reassign 359026 libopenobex
 > retitle 359026 libopenobex: missing build dependency on docbook
 > thanks
 > 
 > Am Sonntag, 26. März 2006 06:02 schrieben Sie:
 > >  > Cited from the arm build log:
 > >  > db2html openobex.sgml
 > >  > output is openobex
 > >  > Using catalogs: /etc/sgml/catalog
 > >  > Using stylesheet: /usr/share/docbook-utils/docbook-utils.dsl#html
 > >  > Working on: /build/buildd/libopenobex-1.2/doc/openobex.sgml
 > >  > openjade:/build/buildd/libopenobex-1.2/doc/openobex.sgml:1:54:W: cannot
 > > generate system identifier for public text "-//OASIS//DTD DocBook V3.1//EN"
 > >
 > > Do you have a build dependency on the docbook package?
 > 
 > Only and indirect dependency by having a build-depends on docbook-utils:
 > docbook-utils depends docbook-dsssl
 > docbook-dsssl depends docbook (>= 3.1) | docbook-xml
 > 
 > So the only reason why the buildd will fail is in the case of already having 
 > docbook-xml installed. But then: why should it work on all but an arm 
 > buildd? 
 > Esspecially since the last time, it worked and nothing changed in that
part.

AIUI, the buildds install packages as needed, but don't clean them up between
builds, so you can get lucky and the package will be there.  Of course, that
does not catch build dependency problems like this.  That's a good reason to
use pbuilder before uploading, since it builds in a clean chroot.

 > 
 > > That's what provides the DocBook 3.1 DTD.
 > 
 > I install docbook-xml manually and removed docbook. Now it fails like on the 
 > arm buildd. Strange, though...

It's not so strange, you are trying to process an SGML file and if you only
install the XML processing package, it fails.

 > I'll make a direct dependency.

I think that is the correct thing to do.

 > 
 > Thanks for solving this problem this fast :)
 > 
 > Hendrik Sattler

No problem. :-)

-- 
Neil Roeth

Reply via email to