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

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: