Hi Colin, On Sun, Jan 31, 2016 at 04:51:26PM +0000, Colin Watson wrote: > Thanks for doing this. > > How frequently will these be updated? It would be nice for people to be > able to upload fixes and see the effects.
Thus far, these are one-shot rebuilds. It is the second attempt of mine. I crossed 1000 source packages last year and worked towards fixing tooling issues. Doing them more frequently is something I would like to see in the future. We already expressed that vision at the bootstrap sprint in 2014. I guess that jenkins.d.n could afford a node doing cross builds, so the missing piece probably just is having someone write the code (https://anonscm.debian.org/git/qa/jenkins.debian.net.git). I can help, but not drive that. > It would also be helpful to publish a dd-list so that maintainers can > easily look for their own packages here. I thought about that option as well, but I believe that we still have too many issues that reside outside the realm of individual packages. A dd-list could mislead maintainers into thinking all of those failures were bugs in their packages. With pkg-config shipping the cross wrapper symlinks now and other examples, this situation is fading. I will keep this in mind for future rebuilds. > Could you help me understand > http://subdivi.de/~helmut/debomatic-logs/groff_1.22.3-5_ppc64el.build ? > This is reported as "uses build arch compiler", but that is a false > positive because groff intentionally does two build passes, one for the > host architecture and one for the build architecture, so that it can use > its own binaries from the build-architecture pass during a cross-build. Correct. These reasons are heuristics and for groff that heuristic failed. > The failure is: > > dh_shlibdeps -a -O--builddirectory=debian/build -O--parallel > dpkg-shlibdeps: error: couldn't find library libstdc++.so.6 needed by > debian/groff-base/usr/bin/pic (ELF format: 'elf64-powerpcle'; RPATH: '') This is usually reported as "dpkg-shlibdeps does not search for libstdc++6 in a sysroot" for other packages, but I failed to improve the heuristic without regressing it on too many other packages. > groff doesn't build-depend on libstdc++-5-dev (which is the correct -dev > package for libstdc++.so.6, despite the confusing naming) because it's > build-essential, and libstdc++-5-dev-ppc64el-cross is likewise > cross-build-essential on ppc64el; I can see it being installed in the > build log. So why can't dpkg-shlibdeps find it here? As a ctte member, you will be aware that there are two ways of building cross compilers and a split on which is better. While it might seem that this only affects the gcc packaging at first, it also does affect dpkg-shlibdeps, whose maintainer has a preference on the other way of maintaining cross toolchains. So crossbuild-essential-ppc64el transitively depends on libstdc++-5-dev-ppc64el-cross, but in your groff build nothing depends on libstdc++-5-dev:ppc64el. So the latter is not installed. Both packages essentially contain the same files albeit in different locations. The former puts files in /usr/powerpc64le-linux-gnu/lib while the latter uses /usr/lib/powerpc64le-linux-gnu. Now dpkg-shlibdeps does not consider sysroots anymore since 1.18.0 and my inquiry to revert that was not met with enthusiasm. So groff crosses just fine once you add libstdc++-5-dev:ppc64el to your CROSSBUILD_CORE_DEPENDS in your sbuildrc. Helmut
