Bug#1061133: libsoup3: Build profiles don't actually work
On Fri, 19 Jan 2024 at 12:34:24 +0100, John Paul Adrian Glaubitz wrote: > Could you perform a new upload of libsoup3 within the next days so I can > bootstrap the package for sh4 again? It isn't my highest priority, but I'll try to get that far down my queue at some point. (Or other GNOME team maintainers are very welcome to take over if someone prioritizes it higher, I don't have any particular sense of ownership over this package.) smcv
Bug#1061133: libsoup3: Build profiles don't actually work
Hi Simon, On Fri, 2024-01-19 at 10:47 +, Simon McVittie wrote: > > From a quick look at libsoup3, it seems like it might only need > > GNUTLS for part of the test suite, and therefore needs to pass > > -Dpkcs11_tests=disabled to meson via dh_auto_configure (overriding > > -Dauto_features=enabled) whenever both of these profiles are disabled? > > Yes, this. Please see the commit that I'm about to push (the commit hook > should set this bug as pending when I do). Thanks for the very quick fix. Could you perform a new upload of libsoup3 within the next days so I can bootstrap the package for sh4 again? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1061133: libsoup3: Build profiles don't actually work
On Fri, 19 Jan 2024 at 00:51:50 +, Simon McVittie wrote: > On Fri, 19 Jan 2024 at 01:17:36 +0100, John Paul Adrian Glaubitz wrote: > > it seems that specifying multiple > > build profiles for a build dependency means that the build dependency is > > removed only if all of the specified profiles are activated. > > It can work either way. You can either write > > dep FYI, this is the one libsoup3 is using (correctly for its particular situation), and it means: (!nocheck) || (!noinsttest) > or > dep whereas this one would mean (!nocheck) && (!noinsttest) and that would be wrong for what libsoup3 is doing. Unfortunately, comparing with architecture restrictions doesn't work as a mnemonic for which way round this is, because positive architecture restrictions like [amd64 i386] are "||", but negative architecture restrictions like [!m68k !sh4] are "&&". This makes sense for architectures because you can only be one architecture at a time, but build profiles can be set or not set independently of each other, so they need a more elaborate syntax. > > This, however, means that that the "nocheck" profile has to be there to > > boostreap libsoup3 which deactivates "libgnutls28-dev" which makes the > > build fail since this build dependency is mandatory. > > *That* sounds like the real bug here. In what way does it fail? Steps to reproduce (on amd64 but I don't think that matters), in a minimal-ish chroot/container (I used debian:sid-slim in Podman): # apt update # apt upgrade # apt build-dep . --arch-only -Pnocheck,noinsttest # dpkg-buildpackage -B -Pnocheck,noinsttest Expected result: - it builds - build-time tests (dh_auto_test) are skipped - the libsoup-3.0-tests package is not generated Actual result: ../meson.build:293:13: ERROR: Dependency "gnutls" not found, tried pkgconfig > From a quick look at libsoup3, it seems like it might only need > GNUTLS for part of the test suite, and therefore needs to pass > -Dpkcs11_tests=disabled to meson via dh_auto_configure (overriding > -Dauto_features=enabled) whenever both of these profiles are disabled? Yes, this. Please see the commit that I'm about to push (the commit hook should set this bug as pending when I do). smcv
Bug#1061133: libsoup3: Build profiles don't actually work
On Fri, 19 Jan 2024 at 01:17:36 +0100, John Paul Adrian Glaubitz wrote: > I was just trying to bootstrap libsoup3 for sh4 using build profiles. > > Unfortunately, that doesn't work since it seems that specifying multiple > build profiles for a build dependency means that the build dependency is > removed only if all of the specified profiles are activated. It can work either way. You can either write dep or dep and they mean different things. I seem to have a blind spot for this and can never remember which way round they are without looking it up, but one of them means "require dep if (!nocheck) && (!noinsttest)" and the other means "require dep if (!nocheck) || (!noinsttest)". Each of them makes sense for some packages and some build profiles. > Thus, in order to strip "libapache2-mod-php" from the build dependencies, > one has to pass "--profile=nocheck,noinsttest" to sbuild, otherwise the > libapache2-mod-php build dependency is still pulled in. That sounds familiar, I think maybe I added that (in libsoup2.4, before the packaging was forked for libsoup3). If it's written this way round, it's probably because the build system will refuse to enable the test suite (either to be run at build-time or to be installed for later use by autopkgtest) if it doesn't detect libapache2-mod-php? A lot of GNOME and GNOME-adjacent packages use the same test executables for build-time and as-installed testing, so it does often make sense to require a build-dependency if (!nocheck) || (!noinsttest) - even if you are not going to run build-time tests, in the absence of noinsttest the package still needs to compile them, in order to populate the -tests package for later use. If that's the case, then yes, to bootstrap it you will have to disable both of those profiles, not just nocheck, and that's probably not a bug. glib2.0 and dbus have a circular dependency on each other that works like this, because each wants to use the other in its test suite, and the way to disable it is to use both build profiles. > This, however, means that that the "nocheck" profile has to be there to > boostreap libsoup3 which deactivates "libgnutls28-dev" which makes the > build fail since this build dependency is mandatory. *That* sounds like the real bug here. In what way does it fail? >From a quick look at libsoup3, it seems like it might only need GNUTLS for part of the test suite, and therefore needs to pass -Dpkcs11_tests=disabled to meson via dh_auto_configure (overriding -Dauto_features=enabled) whenever both of these profiles are disabled? debian/rules in dbus has an example of altering configure options if both build-time and as-installed tests are disabled, if that helps. smcv
Bug#1061133: libsoup3: Build profiles don't actually work
Source: libsoup3 Version: 3.4.4-2 Severity: normal User: debian-sup...@lists.debian.org Usertags: sh4 X-Debbugs-Cc: debian-sup...@lists.debian.org Hello, I was just trying to bootstrap libsoup3 for sh4 using build profiles. Unfortunately, that doesn't work since it seems that specifying multiple build profiles for a build dependency means that the build dependency is removed only if all of the specified profiles are activated. Thus, in order to strip "libapache2-mod-php" from the build dependencies, one has to pass "--profile=nocheck,noinsttest" to sbuild, otherwise the libapache2-mod-php build dependency is still pulled in. This, however, means that that the "nocheck" profile has to be there to boostreap libsoup3 which deactivates "libgnutls28-dev" which makes the build fail since this build dependency is mandatory. Not sure if it's actually a bug in apt which handles multiple profiles per build dependency other than one would expect. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
