Don't know if tests used to pass when it was first keyworded,
but keyword is hardly needed at the moment. Can revisit if we
really need it.
Bug: https://bugs.gentoo.org/935313
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
assimp has issues here like hppa and there should be little
reason to worry about it on ppc given plasma is not due to be
keyworded there and qtquick3d only added ppc due to USE=qml
on qtmultimedia which we can mask.
Bug: https://bugs.gentoo.org/932862
Bug: https://bugs.gentoo.org/935313
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Seems to be little reason to worry about it on ppc as nothing
really need these USE, can revisit if something really needs
these.
Bug: https://bugs.gentoo.org/935313
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Typically still wait a week or so assuming youtube fetching is not
broken, but there's also a minor CVE this time around.. so let's
avoid extra hassle and do it in one go.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Stop renaming musl-fts.pc -> fts-standalone.pc. While it might be more
pure as a name (as it might be useful on other libcs), it's not within our
gift to rename this and it has ecosystem-wide effects.
Other distributions are using the upstream name.
Also, install a symlink for the old fts-standalone name to keep broken
checks working.
While here, fix MisplacedWeakBlocker too.
Closes: https://bugs.gentoo.org/895946
Signed-off-by: Sam James <sam@gentoo.org>
It can be useful to have snapshots in the pre-release period once
the first alpha is out, as various bugs get reported and fixed from
the alpha, and the next pre-release is usually quite far away.
i.e. if it's worth packaging the alpha, it's worth packaging a followup.
Signed-off-by: Sam James <sam@gentoo.org>
It still adds a couple of specific -Werror flags, but these are unlikely to
cause issues for us.
Closes: https://bugs.gentoo.org/934924
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
From "^^ ( elogind systemd )" follows "!systemd == elogind" so use that to
simplify the depspec
Signed-off-by: Paul Zander <negril.nx+gentoo@gmail.com>
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
kde-apps/kaccounts-integration inevitably pulls in -providers which
pulls in dev-qt/qtwebengine.
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
kde-apps/kaccounts-integration inevitably pulls in -providers which
pulls in dev-qt/qtwebengine.
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
kde-apps/kaccounts-integration inevitably pulls in -providers which
pulls in dev-qt/qtwebengine.
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
This package already depends on kde-frameworks/kwallet so in this case
we do not introduce a perceived extra dependency. It is also where Arch
Linux chose to put it.
Closes: https://bugs.gentoo.org/642420
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
kde-apps/kaccounts-integration provides kcm_accounts for systemsettings,
however without kde-apps/kaccounts-providers the list is practically empty
which makes no sense.
So far, only kde-apps/kdenetwork-meta and kde-misc/kio-gdrive had been
pulling it in but we cannot assume every Plasma user would have those
installed.
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
Arches without QtWebEngine keyworded: x32, arm, loong, ppc64, riscv, x86
USE="kf6compat,kaccounts" depends on kde-frameworks/purpose:6[webengine]
which is package.use.mask'ed on these arches. We cannot mask the
combination specifically but in reality kaccounts is useless without
additional dev-qt/qtwebengine revdeps.
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
With only a single available backend left, it does not make that much sense
to rely on a commonly disabled flag to provide major functionality, even if
enabled by default.
Bug: https://bugs.gentoo.org/935033
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>