Re: Tracking strange sgml failures (related to #675613 in dpkg?)
Hi,
Helge Kreutzmann wrote:
> short:
> goobox fails during man page generation (see below) with very similar
> issues like #675613 fixed in dpkg 1.16.4 on some architectures, on
> some not. I'm unable to reproduce, but every time it fails,
> dpkg is < 1.16.4, every time it suceedes, dpkg >= 1.16.4.
>
> Could somebody confirm that I'm on the right track?
>
> If so, is there any other way then using a pre-depency on dpkg >= 1.16.4
> to ensure that buildds are using a recent enough dpkg?
Do you mean build-dependency?
[...]
> amd64 3.0.1-2 suceeded dpkg 1.16.4.3
> amd64 3.0.1-3 failed dpkg 1.16.3
> armel 3.0.1-2 suceeded dpkg 1.16.4.3
> armel 3.0.1-3 suceeded dpkg 1.16.7
> armhf 3.0.1-2 suceeded dpkg 1.16.4.3
> armhf 3.0.1-3 suceeded dpkg 1.16.6
> ia64 3.0.1-2 suceeded dpkg 1.16.4.3
> ia64 3.0.1-3 failed dpkg 1.16.3
> mips 3.0.1-2 suceeded dpkg 1.16.4.2
> mips 3.0.1-3 suceeded dpkg 1.16.4.2
> mipsel 3.0.1-2 failed dpkg 1.16.3
> dpkg 1.16.3
> powerpc 3.0.1-2 suceeded dpkg 1.16.4.3
> 3.0.1-3 suceeded dpkg 1.16.4.3
> s390 3.0.1-2 suceeded dpkg 1.16.4.3
> 3.0.1-3 suceeded dpkg 1.16.4.3
> s390x 3.0.1-2 suceeded dpkg 1.16.4.3
> 3.0.1-3 suceeded dpkg 1.16.4.3
Probably it would be best for the buildds to update their copy of
dpkg. Cc-ing the admins.
Thanks and hope that helps,
Jonathan
Reply to: