Control: reassign 921715 libxinerama1 1.1.4-1
Control: reassign 921712 libxinerama1 1.1.4-1
Control: merge 921715 921712
Control: severity 921715 serious
Control: affects 921715 + libgtk2.0-0-udeb
On Fri, 08 Feb 2019 at 09:27:20 +0000, Mayer, Dirk wrote:
> while building the gtk+2.0 source package on a buster based build system, the
> resulting package libgtk2.0-0-udeb yields a wrong dependency.
> Instead of the correct dependency to the package libxinerama1-udeb it depends
> on the wrong package libxinerama1.
> On the stretch based build system the dependency correctly refers to the udeb
> package.
This seems to be a regression in libxinerama1 1.1.4-1. Its shlibs
metadata doesn't list a record for a udeb:
$ cat /var/lib/dpkg/info/libxinerama1:amd64.shlibs
libXinerama 1 libxinerama1
whereas other X11 udebs have an extra line for udebs, for example:
$ /var/lib/dpkg/info/libxcursor1:amd64.shlibs
libXcursor 1 libxcursor1 (>> 1.1.2)
udeb: libXcursor 1 libxcursor1-udeb (>> 1.1.2)
As a result, when gtk+2.0 is compiled, dh_shlibdeps doesn't know that
its udeb should depend on libxinerama1-udeb.
I think this is because the "--add-udeb=$(PACKAGE)-udeb" option wasn't
preserved during the rewrite of d/rules from traditional debhelper style
to dh.
I've raised this bug to serious severity, because I think it would break the
graphical installer next time gtk+2.0 is rebuilt (we've just been lucky that
the most recent gtk+2.0 upload was a few days before libxinerama1 1.1.4-1). The
X11 and d-i maintainers are of course welcome to reduce the severity if they
disagree with my assessment of its impact.
This probably also affects gtk+3.0, but I don't think debian-installer uses
that yet, so it's only a theoretical issue there.
> Duplicate to Bug #921712 because of wrong package tag
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921712
I've merged the bugs.
Thanks,
smcv
