Control: tags -1 + moreinfo On Thu, 19 Sep 2024 at 20:43:15 +0900, Simon Richter wrote: > when bootstrapping gtk 4, libsysprof-4-dev is one of the indirect build > dependencies of gtk-4, but itself depends on libgtk-4-dev.
libsysprof-4-dev is obsolete and no longer exists in testing/unstable. It was my understanding that new architectures are bootstrapped in unstable, and we do not support adding new architectures to an existing stable release, at least not without deploying a time machine that I don't have access to? Is that wrong? In the trixie cycle, packages that have sysprof capture integration (instrumentation that feeds extra information into sysprof), like glib2.0 and gtk4, should only Build-Depend on libsysprof-capture-4-dev which is a more minimal package without GLib or GTK dependencies. Those packages should also limit their dependency on libsysprof-capture-4-dev to architectures where sysprof already exists (which means it is irrelevant when bootstrapping new architectures), and ideally they should have a build profile to turn off the sysprof integration if re-bootstrapping an existing architecture (for example glib2.0 has pkg.glib2.0.nosysprof which can be used if a re-bootstrap is required). For gtk4 the cycle can also be broken from the sysprof end, by building sysprof with the pkg.sysprof.nogui build profile (see below). gtk4 does not currently have a pkg.gtk4.nosysprof build profile, but it should be easy to add if you want to send a patch (debian/rules already allows building without sysprof on architectures where it isn't buildable, so it should be a simple matter of wiring up the build profile itself). I don't think glib2.0 had its sysprof integration enabled in bookworm, so it presumably didn't participate in any cyclic dependencies. Helmut Grohne has been testing the re-bootstrapping case by using GLib's pkg.glib2.0.nosysprof build-profile (and others), e.g. in https://salsa.debian.org/gnome-team/glib/-/merge_requests/42, and reports that it is successful when using glib2.0 from experimental. glib2.0 in unstable has other re-bootstrapping issues unrelated to sysprof, but fixing those in testing/unstable is currently blocked by getting the new version of src:architecture-properties migrated (#1081799), for which I'm waiting for https://salsa.debian.org/debian/architecture-properties/-/merge_requests/6 to be merged and released. > It would be nice if there was a way to bootstrap, e.g. splitting off the > UI classes into a separate libsysprof-4-ui-dev and a build profile > without these packages This already exists in testing/unstable. The sysprof development files have been split into libsysprof-capture-4-dev (minimal dependencies), libsysprof-6-dev (requires GLib and friends), and the sysprof UI (requires GTK). In testing/unstable there is no longer a public shared library for the UI parts of sysprof, and all of the UI stuff is now internal to sysprof.deb (which can be turned off by building with -Ppkg.sysprof.nogui). A pkg.sysprof.nogui build profile for src:sysprof already existed in bookworm in a different form. I don't know whether that version was fully effective, but if it wasn't, we can't retroactively fix it in the past. smcv