• Bug#1065816: weston: Dependency neatvnc found: NO found 0.8.0 but need:

    From Simon McVittie@21:1/5 to Aurelien Jarno on Sun Mar 10 14:30:02 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)