Bug#948924: [Pkg-cmake-team] Bug#948924: cmake: FTBFS: test failure against libxslt 1.1.34
On Wed, Jan 15, 2020 at 12:21:23AM +0100, Felix Geyer wrote: > > Could you perhaps point me toward the pieace of code in cmake that is > > dealing with this, and what is failing? Perhaps I'm able to help out a > > bit. > > The code is at > https://salsa.debian.org/cmake-team/cmake/blob/master/Modules/FindLibXslt.cmake > If pkg-config is installed it takes the version from there and everything > should work fine. > Otherwise it uses the path of libxslt/xslt.h and parses the version from > xsltconfig.h in the same path. This fails as xsltconfig.h is in a different > path. But as you pointed out this already fails with the package from > unstable. > > The problem is actually triggered by having libxslt1-dev installed in your > build chroot. In a clean cmake package build libxslt1-dev is not installed > and cmake just skips the tests that fails in your build. Oh wow. So it turns out that my attempt at hastening the rebuilds by pre-installed the new binaries in the choort backfired here. Having said that, reading that .cmake file is't not clear to me why it would skip the test if libxslt1-dev is not installed. > So we can > a) ignore it (until the cmake build somehow pulls in libxslt) I'd probably go for this and close this bug if you agree. > b) make cmake build-depend on pkg-config Your call. > c) move all xslt headers into the same path I'd rather avoid changing upstream's configuration even more. There is also a d) have that .cmake file use find_path() also to detect the path of libxslt/xsltconfig.h, instead of assuming it lives with xslt.h. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#948924: [Pkg-cmake-team] Bug#948924: cmake: FTBFS: test failure against libxslt 1.1.34
On 14.01.20 23:33, Mattia Rizzolo wrote: Hi Felix, thank you for the quick follow up On Tue, Jan 14, 2020 at 10:29:26PM +0100, Felix Geyer wrote: your package failed to rebuild in a sid/amd64 chroot against libslt 1.1.34. The problem seems to be that cmake's FindLibXslt can't deal with the headers being split across /usr/include and /usr/include/. Why do you say so? That part hasn't change for many many years (since 2017! version 1.1.29-3), and in particular doesn't change between the version currently in unstable and experimental: You are right of course. I jumped to my conclusion a bit too early. I forgot to mention indeed that besides dropping the xslt-config I also dropped the static library, I hope that cmakes doesn't depend on it :) Would you consider moving all headers to /usr/include/? This should make libxslt's packaging easier and avoid special cases in build systems like cmake that try to detect it. The fact that the single file xsltconfig.h is within the arch-specific path indeed comes from the packaging and I could move it all; that said, I can't imagine why cmake would even notice such thing. Tring to '#include ' ought to work regardless; if you are depending and checking the specific location of header files that are places in standard location, I deem to say that you are not doing yourself any favour. :) Could you perhaps point me toward the pieace of code in cmake that is dealing with this, and what is failing? Perhaps I'm able to help out a bit. The code is at https://salsa.debian.org/cmake-team/cmake/blob/master/Modules/FindLibXslt.cmake If pkg-config is installed it takes the version from there and everything should work fine. Otherwise it uses the path of libxslt/xslt.h and parses the version from xsltconfig.h in the same path. This fails as xsltconfig.h is in a different path. But as you pointed out this already fails with the package from unstable. The problem is actually triggered by having libxslt1-dev installed in your build chroot. In a clean cmake package build libxslt1-dev is not installed and cmake just skips the tests that fails in your build. So we can a) ignore it (until the cmake build somehow pulls in libxslt) b) make cmake build-depend on pkg-config c) move all xslt headers into the same path Cheers, Felix
Bug#948924: [Pkg-cmake-team] Bug#948924: cmake: FTBFS: test failure against libxslt 1.1.34
Hi Felix, thank you for the quick follow up On Tue, Jan 14, 2020 at 10:29:26PM +0100, Felix Geyer wrote: > > your package failed to rebuild in a sid/amd64 chroot against libslt 1.1.34. > > The problem seems to be that cmake's FindLibXslt can't deal with the headers > being split across /usr/include and /usr/include/. Why do you say so? That part hasn't change for many many years (since 2017! version 1.1.29-3), and in particular doesn't change between the version currently in unstable and experimental: % debdiff libxslt1-dev_1.1.32-2.2_amd64.deb libxslt1-dev_1.1.34-1_amd64.deb |grep -v doc [The following lists of changes regard files as different if they have different names, permissions or owners.] Files in second .deb but not in first - lrwxrwxrwx root/root /usr/lib/x86_64-linux-gnu/libxslt.so -> libxslt.so.1.1.34 Files in first .deb but not in second - -rw-r--r-- root/root /usr/lib/x86_64-linux-gnu/libexslt.a -rw-r--r-- root/root /usr/lib/x86_64-linux-gnu/libxslt.a -rw-r--r-- root/root /usr/share/man/man1/xslt-config.1.gz -rwxr-xr-x root/root /usr/bin/xslt-config lrwxrwxrwx root/root /usr/lib/x86_64-linux-gnu/libxslt.so -> libxslt.so.1.1.32 I forgot to mention indeed that besides dropping the xslt-config I also dropped the static library, I hope that cmakes doesn't depend on it :) > Would you consider moving all headers to /usr/include/? This should make > libxslt's packaging easier and avoid special cases in build systems like cmake > that try to detect it. The fact that the single file xsltconfig.h is within the arch-specific path indeed comes from the packaging and I could move it all; that said, I can't imagine why cmake would even notice such thing. Tring to '#include ' ought to work regardless; if you are depending and checking the specific location of header files that are places in standard location, I deem to say that you are not doing yourself any favour. :) Could you perhaps point me toward the pieace of code in cmake that is dealing with this, and what is failing? Perhaps I'm able to help out a bit. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#948924: [Pkg-cmake-team] Bug#948924: cmake: FTBFS: test failure against libxslt 1.1.34
Hi Mattia, On 14.01.20 21:42, Mattia Rizzolo wrote: Source: cmake Version: 3.15.4-1 Severity: important Tags: ftbfs User: libx...@packages.debian.org Usertags: ftbfs-34 Dear maintainer, your package failed to rebuild in a sid/amd64 chroot against libslt 1.1.34. In particular, that version is not shipping the xslt-config script anymore, to push people toward pkg-config more. It may be relevant here. Attached is the full build log, hopefully relevant excerpt follows: The problem seems to be that cmake's FindLibXslt can't deal with the headers being split across /usr/include and /usr/include/. Would you consider moving all headers to /usr/include/? This should make libxslt's packaging easier and avoid special cases in build systems like cmake that try to detect it. Imho the disk space overhead when you have libxslt1-dev from multiple archs installed is negligible. Cheers, Felix
