Control: affects 901771 src:gtkdataboxmm src:libgtkdatabox src:osm-gps-map src:sugar-toolkit-gtk3 src:fontforge Control: severity 901771 serious Control: tags 901771 + patch
On Thu, 19 Apr 2018 at 23:56:18 -0400, Jeremy Bicha wrote: > The build itself completes fine. If pango were broken, I'd expect a > lot more bug reports. > > But it's the d-shlibmove command that fails. Note this line in the build log: > > > devlibs error: There is no package matching [libfribidi0-dev] and noone > > provides it, please report bug to d-shlibs maintainer On Fri, 20 Apr 2018 at 09:09:12 +0300, Adrian Bunk wrote: > d-devlibdeps basically contains a manual mapping to the -dev packages > in such cases, this is horribly fragile. I was about to clone this bug to d-shlibs, because that's clearly a bug in d-shlibs, orthogonal to whether anything is wrong with pango1.0; but <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901771> was reported in the meantime, so let's use that one instead. I'm escalating #901771 to RC, because d-shlibs is clearly not helping here, and the solution is trivial; see attached 0001-Add-quirk-for-libfribidi-dev.patch, which I have confirmed fixes the build of src:libgtkdatabox (patches also on the way for the existing RC bug #897539). I've also opened a bug suggesting that d-devlibdeps should be deprecated. > In this specific case the root problem is that using pango results in > needlessly linking with libfribidi, which can also become annoying for > transitions. > > This would otherwise not be a FTBFS-causing RC bug, but it is an easily > fixable bug that should be fixed. Normally, I'd say fribidi should be moved from Requires to Requires.private (or the Requires.internal proposed on <https://bugs.freedesktop.org/show_bug.cgi?id=105572>, but that doesn't exist yet) to resolve this while not breaking static linking; and I'd also say we should augment debian/tests/build to exercise static linking, to prove that that can still work. However, libfribidi in Debian doesn't provide a static library any more, so static linking can't actually work anyway. I've asked fribidi upstream whether they intend to be only supporting shared linking, or whether their change of defaults was misinterpreted by the Debian maintainer of fribidi as having been a policy change: https://github.com/fribidi/fribidi/issues/83 Either moving this dependency from Requires to Requires.private or removing it altogether is clearly an improvement, so I think we should do one or the other, and I'm very tempted to pick one arbitrarily and JFDI, with the intention of swapping to the other if the result of fribidi#83 indicates that the opposite would be better. smcv