>=dev-qt/qtbase-${QTMIN}:6=[gui] for qtx11extras_p.h
>=dev-qt/qtwayland-${QTMIN}:6= for private/qwayland*_p.h
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
Berk Elyesa Yıldırım (1):
Drop legacy keys for m_runOnDiscreteGpuBool
Jonathan Marten (1):
kioexec: Remove temporary files after the main loop has completed
Martin Seher (1):
fix hide service menu items in context menu
Méven Car (2):
KFileitem: Use internal permissions as best case scenario
KFileItem: when checking access use current user
Nicolas Fella (4):
[knewfilemenu] Fix error handling when creating a folder that already exists
[kterminallauncherjob] Inherit default process environment from parent
[knewfilemenu] Add window title for new file dialog
[kfileplacesmodel] Remove wrong assert
Patrycja Rosa (1):
Fix sprintf buffer leaks on 32-bit systems
Sergey Katunin (1):
Revert "Temporarily revert "Consider slow files as remote files in previewjob""
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
Uses Qt6::GuiPrivate for qiconloader_p.h, qguiapplication_p.h
Backporting to 6.0.0, otherwise this dependency fix would only be
introduced by 6.1.0 on April 13th.
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
test-flags-CC was not meant to test LDFLAGS and -Wl,* are no-ops
at compile-time and thus don't get stripped even if they don't work
(same happens when using strip-unsupported-flags) and then if a
package compiles and links anything at same time it fails.
This used not to be a big problem but now that 23.0 profiles
do -Wl,-z,pack-relative-relocs (mingw ld has no -z) this is
hitting bashrc-mv users that tend to do CFLAGS="${LDFLAGS}"
by default. Tempting to ignore it because of how wrong it is,
but well.
An alternate route could be to eventually have strip-flags
and/or strip-unsupported-flags remove -Wl,* from non-LDFLAGS
given this could affect more than mingw (e.g. switching to
bfd when there is a lld-only option).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
test-flags-CC was not meant to test LDFLAGS and -Wl,* are no-ops
at compile-time and thus don't get stripped even if they don't work
(same happens when using strip-unsupported-flags) and then if a
package compiles and links anything at same time it fails.
This used not to be a big problem but now that 23.0 profiles
do -Wl,-z,pack-relative-relocs (mingw ld has no -z) this is
hitting bashrc-mv users that tend to do CFLAGS="${LDFLAGS}"
by default. Tempting to ignore it because of how wrong it is,
but well.
An alternate route could be to eventually have strip-flags
and/or strip-unsupported-flags remove -Wl,* from non-LDFLAGS
given this could affect more than mingw (e.g. switching to
bfd when there is a lld-only option).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
test-flags-CC was not meant to test LDFLAGS and -Wl,* are no-ops
at compile-time and thus don't get stripped even if they don't work
(same happens when using strip-unsupported-flags) and then if a
package compiles and links anything at same time it fails.
This used not to be a big problem but now that 23.0 profiles
do -Wl,-z,pack-relative-relocs (mingw ld has no -z) this is
hitting bashrc-mv users that tend to do CFLAGS="${LDFLAGS}"
by default. Tempting to ignore it because of how wrong it is,
but well.
An alternate route could be to eventually have strip-flags
and/or strip-unsupported-flags remove -Wl,* from non-LDFLAGS
given this could affect more than mingw (e.g. switching to
bfd when there is a lld-only option).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
mingw64-*-11 been gone for a while now.
Was originally thinking to add the same workaround as mingw64-toolchain
for -Wl,-z,* but meson does not need this. So isntead cleaning this up.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
mingw64-*-11 been gone for a while now.
Was originally thinking to add the same workaround as mingw64-toolchain
for -Wl,-z,* but meson does not need this. So isntead cleaning this up.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
strip-unsupported-flags handles this fine in LDFLAGS, but -Wl,*
are no-ops during compile-only tests (thus not stripped) and then
if a package compiles and links anything at same time it fails.
This used not to be a big problem but now that 23.0 profiles
do -Wl,-z,pack-relative-relocs (mingw ld has no -z) this is
hitting bashrc-mv users that tend to do CFLAGS="${LDFLAGS}"
by default. Tempting to ignore it because of how wrong it is,
but well.
An alternate route could be to eventually have strip-flags
and/or strip-unsupported-flags remove -Wl,* from non-LDFLAGS
given this could affect more than mingw (e.g. switching to
bfd when there is a lld-only option).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
strip-unsupported-flags handles this fine in LDFLAGS, but -Wl,*
are no-ops during compile-only tests (thus not stripped) and then
if a package compiles and links anything at same time it fails.
This used not to be a big problem but now that 23.0 profiles
do -Wl,-z,pack-relative-relocs (mingw ld has no -z) this is
hitting bashrc-mv users that tend to do CFLAGS="${LDFLAGS}"
by default. Tempting to ignore it because of how wrong it is,
but well.
An alternate route could be to eventually have strip-flags
and/or strip-unsupported-flags remove -Wl,* from non-LDFLAGS
given this could affect more than mingw (e.g. switching to
bfd when there is a lld-only option).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Andreas Sturmlechner
Mart Raudsepp
Andrew Ammerlaan
Arthur Zamarin
Mike Gilbert
Zac Medico
Florian Schmaus
Ulrich Müller
Ionen Wolkens