Andreas Sturmlechner

Same with x11-libs/qscintilla ``` UnusedInherits: version 2.13.1: unused eclass: qmake-utils UnusedInherits: version 2.13.3: unused eclass: qmake-utils ``` uses eqmake5: ``` run_in_build_dir eqmake5 -recursive ${MY_PN}.pro ```

Indeed seeing the same when preparing hundreds of version bumps in a wip-branch: ``` kde-apps/pimcommon UnstableOnly: for arch: [ ppc64 ], all versions are unstable: [ 21.08.3, 21.12.0 ] NonexistentBlocker:...

See also full build.log in downstream bug report: https://bugs.gentoo.org/906470 Arch Linux use a non-upstreamed patch for >=3.30.3: https://gitlab.archlinux.org/archlinux/packaging/packages/qgis/-/blob/main/exiv2-0.28.patch

@ggardet well it is not my patch, but maybe @antonio-rojas would

1) There is no such thing as maintenance mode in a source-based distribution. Every package we provide must be able to build with an up to date toolchain, newer versions...

That seems to imply Stellarium with Qt6 QML does not have the same limitations/less functionality as a theoretical Qt5 QML version? @DarthGandalf: Possible, the only downside is potentially pulling in...

I did something to that effect in my workaround: https://github.com/supercollider/supercollider/compare/develop...a17r:supercollider:workaround-boost-1.84

> However, the libraries now install as libxyz-Qt5.so and libxyz-Qt6.so, breaking old packages that expect just libxyz.so Do we need a `:=` slot op on Qt5-based revdeps or is patching...

ping - this is now blocking 24.02.0 (among many other things though ;))

@dflogeras: Apologies about the situation, I usually try my best to avoid wasted efforts. The bug was filed before I knew about the need for Qt5-based revdeps to be patched...