Control: block 1036884 by -1 On Sun, 10 Mar 2024 at 10:37:51 +0100, Aurelien Jarno wrote: > weston fails to build in unstable since the upload of neatvnc in version > 8.0. From my build log on amd64: ... > | Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= > 0.7.0'
This is important for the 64-bit time_t transition, because weston is part of that transition, and also because packages like gtk4 use weston in headless mode to test their Wayland backends. This could be mitigated by temporarily making gtk4 skip its Wayland tests on 32-bit architectures, but with gtk4 hat on, I would not be comfortable with doing that in the long term, because in practice it seems to be inevitable that functionality that isn't tested doesn't actually work. Looking at the recent neatvnc upload, I was surprised to see that its former maintainer updated it to a new upstream release in the same upload as orphaning it (#1065738), and also updated the closely-related wayvnc package to a new upstream release that matches neatvnc. I also noticed that neatvnc 0.8.0 has an ABI break without bumping the SONAME (#1065824), although that might be ignorable since nothing in Debian seems to use the affected symbol. I think the options here in the short term are: 1. adapt weston to support neatvnc 0.8.0, if it's straightforward to do so; 2. revert neatvnc to 0.8.0+really0.7.1+dfsg and wayvnc to 0.8.0+really0.7.2, and revisit this later, when we are *not* in the middle of a transition that touches thousands of packages; 3. temporarily disable the VNC backend in weston, and revisit this later I would personally be very tempted by (2.) since it seems like the option with least risk of regressions when compared with what's currently in trixie, but I have no particular knowledge of these packages, so it would be better if the maintainers of weston and/or wayvnc could adopt neatvnc and handle this in whatever way they prefer. If this situation is not resolved then I might do the revert (2.), by QA-uploading neatvnc and NMU'ing wayvnc. Thanks, smcv