Processed: Re: Bug#1070706: gtk4 udeb has unsatisfiable dependencies
Processing control commands: > severity 1070706 normal Bug #1070706 [gtk4] gtk4 udeb has unsatisfiable dependencies Severity set to 'normal' from 'serious' > severity 1070714 normal Bug #1070714 [src:vte2.91] libvte-2.91-0-udeb depends on both GTK 3 and GTK 4 Severity set to 'normal' from 'serious' -- 1070706: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070706 1070714: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070714 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1070706: gtk4 udeb has unsatisfiable dependencies
Control: severity 1070706 normal Control: severity 1070714 normal On Tue, 07 May 2024 at 22:53:33 +0200, Cyril Brulebois wrote: > Simon McVittie (2024-05-07): > > do the release/installer teams consider udeb dependencies > > on non-udeb packages, by udebs that d-i does not currently need or use, > > to be a RC issue or merely a nice-to-have? > > If udebs are actually used, I call that an RC bug and try to get it > fixed swiftly (sometimes NMUing right away when time is of the essence). > Otherwise I usually let those fly (without even filing bug reports). In that case I'm downgrading #1070714 and #1070706 to normal, because the issues I noticed while investigating #1070706 are worth tracking and being aware of but non-RC, and the issue that Peter originally reported is not actionable for the gtk4 maintainers (it needs to be fixed via a binNMU). We'll need to revisit #1070714 and #1070706 if someone makes a concerted effort to GTK3ize the installer, but that has been on my to-do list since before bookworm and shows no signs of approaching the top, so it might have to be someone else's project. Thanks! smcv
Bug#1070706: gtk4 udeb has unsatisfiable dependencies
On Tue, 07 May 2024 at 22:02:12 +0200, Paul Gevers wrote: > On 07-05-2024 7:49 p.m., Simon McVittie wrote: > > The version in testing, 4.12.5+ds-3, has the same dependencies, so this > > is not a regression. > > Is it? It seems that the version in unstable depends on libpng16-16t64-udeb > where the version in testing depends on libpng16-16-udeb. The later exists, > the former not. Oh, well spotted! It looks as though src:gtk4 needs a binNMU against libpng-dev (>= 1.6.43-4) for #1066069, because we were unlucky with the timing of gtk4's most recent upload and so it got built against the incorrect libpng-dev. My understanding is that a binNMU would be better than a sourceful upload of gtk4 because it won't reset the migration clock. If that's correct, please could someone with release team or wanna-build powers schedule it? nmu gtk4_4.12.5+ds-6 . ALL . -m 'rebuild with #1066069 fixed' Looking at the d-i Packages.gz for amd64, the only other source package that has picked up the bad libpng16-16t64-udeb dependency seems to be matchbox-keyboard, which needs a sourceful upload to fix an implicit-declarations FTBFS anyway, therefore isn't useful to binNMU. After those binNMUs, the gtk4 udeb will still not be installable into the debian-installer environment (either in testing or in unstable), but it should at least be able to migrate, because all of its dependencies will be packages that exist (whether deb or udeb). After that: do the release/installer teams consider udeb dependencies on non-udeb packages, by udebs that d-i does not currently need or use, to be a RC issue or merely a nice-to-have? Thanks, smcv
Bug#1070706: gtk4 udeb has unsatisfiable dependencies
Hi, On 07-05-2024 7:49 p.m., Simon McVittie wrote: The version in testing, 4.12.5+ds-3, has the same dependencies, so this is not a regression. Is it? It seems that the version in unstable depends on libpng16-16t64-udeb where the version in testing depends on libpng16-16-udeb. The later exists, the former not. Is this requirement newly enforced by britney? No. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: Re: Bug#1070706: gtk4 udeb has unsatisfiable dependencies
Processing control commands: > tags -1 + d-i Bug #1070706 [gtk4] gtk4 - udebs broken. Added tag(s) d-i. > found -1 4.12.5+ds-3 Bug #1070706 [gtk4] gtk4 - udebs broken. There is no source info for the package 'gtk4' at version '4.12.5+ds-3' with architecture '' Unable to make a source version for version '4.12.5+ds-3' Marked as found in versions 4.12.5+ds-3. > retitle -1 gtk4 udeb has unsatisfiable dependencies Bug #1070706 [gtk4] gtk4 - udebs broken. Changed Bug title to 'gtk4 udeb has unsatisfiable dependencies' from 'gtk4 - udebs broken.'. > clone -1 -2 Bug #1070706 [gtk4] gtk4 udeb has unsatisfiable dependencies Bug 1070706 cloned as bug 1070714 > retitle -2 libvte-2.91-0-udeb depends on both GTK 3 and GTK 4 Bug #1070714 [gtk4] gtk4 udeb has unsatisfiable dependencies Changed Bug title to 'libvte-2.91-0-udeb depends on both GTK 3 and GTK 4' from 'gtk4 udeb has unsatisfiable dependencies'. > reassign -2 src:vte2.91 0.75.92-1 Bug #1070714 [gtk4] libvte-2.91-0-udeb depends on both GTK 3 and GTK 4 Bug reassigned from package 'gtk4' to 'src:vte2.91'. No longer marked as found in versions 4.12.5+ds-3 and 4.12.5+dfsg-6. Ignoring request to alter fixed versions of bug #1070714 to the same values previously set Bug #1070714 [src:vte2.91] libvte-2.91-0-udeb depends on both GTK 3 and GTK 4 Marked as found in versions vte2.91/0.75.92-1. -- 1070706: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070706 1070714: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070714 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1070706: gtk4 udeb has unsatisfiable dependencies
Control: tags -1 + d-i Control: found -1 4.12.5+ds-3 Control: retitle -1 gtk4 udeb has unsatisfiable dependencies Control: clone -1 -2 Control: retitle -2 libvte-2.91-0-udeb depends on both GTK 3 and GTK 4 Control: reassign -2 src:vte2.91 0.75.92-1 On Tue, 07 May 2024 at 15:44:02 +0100, Peter Michael Green wrote: > According to britney, gtk4's udebs are uninstallable. gtk4 is not yet used by debian-installer (which is still on GTK 2) so the udeb is not actually necessary, and one workaround would be to disable it entirely (but then we'd have to put GTK 4 through NEW again if we are ever able to upgrade d-i to it). The version in testing, 4.12.5+ds-3, has the same dependencies, so this is not a regression. Is this requirement newly enforced by britney? I think a large part of the problem is that when GTK 4 support was added to src:vte2.91, both the GTK 3 and GTK 4 versions were put into the same udeb package, libvte-2.91-0-udeb, instead of giving the GTK 4 version its own udeb. However, I'm unsure how that change got into testing - if britney is enforcing installability of udebs, I would have expected that the updated libvte-2.91-0-udeb would have been newly-uninstallable, preventing its migration? It seems most realistic that d-i in Debian 13 will depend on GTK 3 if someone finds the time to do the necessary porting and testing, or stay on GTK 2 if not, so libvte-2.91-0-udeb should become a udeb version of only libvte-2.91-0 (i.e. GTK 3 only) as it was in Debian 12, and drop its GTK 4 parts. That would mean that GTK 4 would no longer be regressing the installability of libvte-2.91-0-udeb. If there is a serious attempt to get d-i using GTK *4*, then that would require a new libvte-2.91-gtk4-0-udeb. However, GTK 4's threading model is definitely incompatible with the current design of cdebconf-gtk (it calls into GTK from more than one thread, which is discouraged in GTK 3 and not allowed at all in GTK 4), so a prerequisite for that would be to move all of cdebconf-gtk's GTK interactions onto one thread, with message-passing between that thread and the cdebconf thread. I'm also unsure how GTK 4 can possibly have caused libvte-2.91-0-udeb's installability to regress anyway, because libvte-2.91-0-udeb in testing depends on liblz4-1, which does not have a corresponding udeb. That will need fixing (by adding a liblz4-1-udeb, or linking it statically, or allowing .deb libraries to satisfy udebs' dependencies) if we ever want a GTK 3 or later installer. Making the GTK 4 udeb installable looks like a significant task. It depends on: OK - fontconfig-udeb (>= 2.15.0), OK - libc6-udeb (>= 2.37), !! - libcairo-script-interpreter2 (>= 1.18.0), OK - libcairo2-udeb (>= 1.18.0), OK - libepoxy0-udeb (>= 1.5.4), OK - libfribidi0-udeb (>= 1.0.13), OK - libgdk-pixbuf-2.0-0-udeb (>= 2.42.10+dfsg), OK - libglib2.0-udeb (>= 2.78.4), !! - libgraphene-1.0-0 (>= 1.10.8), OK - libharfbuzz0-udeb (>= 8.3.0), !! - libjpeg62-turbo (>= 1:2.1.5), OK - libpango1.0-udeb (>= 1.52.1+ds), OK - libpng16-16t64-udeb (>= 1.6.2), !! - libtiff6 (>= 4.5.1+git230720), OK - libx11-6-udeb (>= 2:1.6.0), OK - libxcursor1-udeb (>> 1.1.2), !! - libxdamage1 (>= 1:1.1), OK - libxext6-udeb (>= 2:1.3.0), OK - libxfixes3-udeb (>= 1:5.0), OK - libxi6-udeb (>= 2:1.6.99.1), OK - libxinerama1-udeb (>= 2:1.1.4), OK - libxrandr2-udeb (>= 2:1.5) cairo has a udeb, but it doesn't include the equivalent of libcairo-script-interpreter2. It might be possible to disable the GTK features that rely on that library? Or it might be possible to add the script interpreter to the udeb? graphene does not have udebs at all, and I think it's a mandatory dependency for GTK 4, so if we ever want a GTK-4-based d-i, there is no avoiding adding a graphene udeb. libjpeg-turbo, tiff and libxdamage are in the same situation as graphene (these were optional in GTK 3 but are required in GTK 4). Unlike graphene, these are not maintained by the GNOME team, so we cannot unilaterally add udebs to them. smcv