| Age | Commit message (Collapse) | Author |
|---|
|
Had kind of forgot about this one and it's been fixed for a while,
upstream fix was a bit different so the patch still applied.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Technically "screencast" was wrong here, it was for a screen capture
feature, and (haven't tried) but commit history seem to imply that
it's usable for audio as well now.
So let's just use "pipewire".
It's also now possible to make dbus optional given options were split.
Also := on pipewire is actually needed, screen capture is only through
dbus but other features dlopen it and rely on PW_API_VERSION to figure
out which library to load (requires a rebuild to update if changed)
While here, cleanup the gstreamer [X=] workaround -- libX11 now has
a xorg-proto RDEPEND and X= was a hack. We can keep our own DEPEND
xorg-proto even if technically unneeded though.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
>=6.8.2 adds a new subtest that seems to loop through supported
formats, and that seems to end up messy depending on what the
system ffmpeg/gst supports.
Being new (should not be a regression), skip for now, may revisit.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
QVersionNumber is only used with USE="gstreamer pulseaudio", but the
required header is not included for it. Seems works with USE="vulkan"
given Qt vulkan headers just happen to include it.
Furthermore only fails with clang, albeit haven't looked for what is
being treated differently with it (perhaps a version check somewhere
includes the header with gcc).
Closes: https://bugs.gentoo.org/947606
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
A change in tst_qmediaplayer_gstreamer causes it to attempt to use
real pulseaudio which doesn't work here. Might add that upstream
recently starting skiping all gstreamer tests (QTBUG-129469) in
their CI while recognizing that they're flaky.
And tst_qmediarecorderbackend seems to be trying to use ffmpeg+nvenc
for me which does not end well... May possibly pass depending on
USE on ffmpeg but rather not have to worry about this.
On a side-note, this was the last known (non-)issue with Qt 6.8.1
branch and it should be ready for release.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Not an ideal "fix" for ppc32, but rather go for a simple workaround
if it's 32bit arches (esp. ppc32) and it's non-invasive to keep.
Still not quite sure why ppc32 surfaced as an issue now except maybe
different gcc? The bit about Qt passing -maltivec been there since
Qt 6.4 (long before we keyworded+stabilized it for ppc) unless I'm
overlooking something. And then (for the ppc64 issue) dev-cpp/eigen
only received the vsx patch somewhat recently, albeit that one is
due to some more specific hardware so it makes more sense.
Closes: https://bugs.gentoo.org/943402
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
This seems fixed now.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
ebuild's comment is currently incorrect given build system does not
pass this, but KDE is planning to upstream it to be passed the same
way as PFFFT's so may as well pass it together and leave the comment.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
May possibly be needed in 6.7.9999 too given it received some
gstreamer changes, have not tried yet.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Bit of a edge case so revbump is not essential, but rather avoid
potential weird states in middle of Plasma 6 migration.
Closes: https://bugs.gentoo.org/938890
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Fixed upstream.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Originally thought it added native pipewire audio support, but this
is only for screencast and so not doing USE=pipewire.
Split off [X=] hack and add a redundant [X?] in case we are ever
able to remove it (aka gst not broken without xorg-proto, xorg-proto
in RDEPEND, or if a new EAPI adds a way declare DEPEND-only deps for
reverse deps).
gst[egl] could technically be optional, but feel it's not worth
introducing a USE. Arguably feel it should be unconditionally
enabled on gst if USE=opengl.
Updating the ebuild also exposed a bug in cmake's checks with gl_x11
and gl_wayland, been reported and doing a temporary workaround for now.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Just so it builds, it's not the only problem (also 3 test failures
to investigate, but will leave that for when it's closer to release).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Could revisit enabling both if qtmultimedia tries higher-end
backends like pulseaudio first in the future, but currently
it is both marked experimental and without autodetect:
qt_feature("alsa" PUBLIC PRIVATE
LABEL "ALSA (experimental)"
AUTODETECT false
So only enable it if it's the only option we have.
Have not checked the state of this for Qt5, but probably better
off not touching at this point unless someone has problems
(it's possible the audio sink was going through gstreamer
preventing issues).
Closes: https://bugs.gentoo.org/935146
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
New test added in 6.7.1 and failing while attempting to use
h264_v4l2/cuvid and such. Passes fine if ran directly under X.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Closes: https://bugs.gentoo.org/928420
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Have not verified if 6.6.x did this one too (perhaps overlooked
last time checked), but noticed in 6.7 anyhow.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Intentionally skipping revbump, see bug #925597's comments.
Closes: https://bugs.gentoo.org/925597
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Albeit changes nothing given using a REQUIRED_USE, but like X= this
is for screencapture and should be together.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Spotted the (new) need for this looking at differences between 6.6.1
and upcoming 6.6.2.
Fortunately very few users should be using eglfs so it hopefully
won't disrupt too much (albeit some may have enabled because wayland
REQUIRED_USE formerly requested it even though it was not needed).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Test was modified to be more strict and newly fails with offscreen
rendering. Passes fine when using the RHI backend rather than CPU
conversion (afaik wouldn't work with virtx+sandbox either).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Already depended on libglvnd for it but seems it needs support in
QT as well (does not check/use QtOpenGL but qopenglfunctions.h is
emptied by a #ifndef when disabled, resulting in messy errors
rather than a missing header).
Due to the required uses, can unify the libglvnd dep now.
Closes: https://bugs.gentoo.org/920232
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
When vulkan is enabled, qtbase has to be built with vulkan support, and
a bunch of private qt headers are poked at. Those headers privately make
use of the bdep which qtbase itself has (USE-conditional on vulkan), but
since it is only a build time dependency it is not necessarily
guaranteed to be installed when building qtmultimedia.
Often it will be installed, since qtbase does after all drag it in. But
e.g. when building qtmultimedia from source, but getting qtbase via a
binpkg, no bdeps for qtbase are available.
Since this is private headers stuff, it makes a certain amount of sense
that qtmultimedia should be independently responsible for adding the
same bdep on its own, rather than forcing qtbase to runtime depend on
it.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Closes: https://github.com/gentoo/gentoo/pull/33911
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Fails to find a real window, would likely work if used Xvfb and
the xcb backend but feel it's not bothering for these.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Similarly to the other screencapture test, may try weird
things if happen to have support in ffmpeg or gstreamer.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Handling changed a bit and does not need to link with libva,
it does want ffmpeg[vaapi] though.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Less jarring a little bit shorter. Made sense in Qt5 given it used
a ver_cut QT5_PV and could be used to ignore additional components,
but with PV it does nothing useful. Plus we still want _rc and _betas
to match (_p<date> are where issues start though, if ever needed we
could reintroduce QT6_PV, but for now...).
Should have done this in the previous style commit.
Still keeping :6, do prefer these being everywhere for clarity with
Qt slots (and qa-vdb!) even if essentially a no-op here. Plus, even
if this does not happen with Qt, two slots having the same version
can happen with revisions (e.g. current webkit-gtk).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Hopefully right, kind of confusing.
Notes:
* qtbase[X=]: checks qtbase for wether to use xlib or not,
we "could" probably force xlib off safely in "this" case
but that still tend to be messy with Qt's ABI
* gst[X=]: similarly checks if enabled through defines, may
possibly break without this if build against gst[X] then
disable it
* qtbase[opengl=,vulkan=]: untested but source is literred in
QT_CONFIG(opengl) and some (vulkan) and would most likely
break if not matching like others (e.g. qtdeclarative) are
known to
* ^ but for gstreamer, we can use gstreamer_gl feature
* qtshadertools is only used to call qsb that I can see, so
move to BDEPEND, albeit does come with the caveat that
(unlike qtdeclarative), it does not look for it separately
to find it during cross-compilation
* qtsvg seems only used by examples, dropping may however have
the downside that very few packages pull qtsvg and it is often
needed by other applications (but it is wrong here)
* pulse[glib] dropped, may have been needed in the past but failing
to see the need for USE=glib right now
X is enabled by default on qtbase, gst-plugins-base, and
here, so it should hopefully not cause mismatch headaches
even on non-desktop profiles (assuming users don't try to
manually enable X/opengl/vulkan per-packages). Pure wayland
systems should be able to avoid X11 entirely with Qt6.
Note that it "looks" for gstreamer even when it is disabled,
so it may give xorg-proto warnings (if missing) if gst was built
with USE=X. Non-issue given in that situation we don't use
gstreamer. If gst[-X], then xorg-proto is not needed at all.
Closes: https://bugs.gentoo.org/910364
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Not that doing keywording at the moment, but does not hurt to be
prepared (due to a cmake string comparing i*86 with what is likely
x86_64 in the chroot), and then leading to intrinsic inlining failed
build issues.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Imagine may be more that will need skipping. In my case one
test tried to use NVENC/CUDA but there may be more on systems
that support e.g. vaapi (unlike mine).
Unfortunately have not found a way to tell qtmultimedia to
use a dummy audio input/output wrt the other tests.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Misc minor adjustments / sorting, but more commonly:
* use same RDEPEND + DEPEND ordering everywhere, bit of both
order is used all across and sometime inverted in Qt5's so
let's match skel.ebuild to avoid confusion
* use explicit :6 slots, not necessary with =PV but this is more
about normalizing usage when multiple slots exist (plus *cough*
qa-vdb won't complaint anymore)
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
As-is, no changes in this commit which is mostly the same
as the current in-tree ebuilds.
Maintaining these in two different repos feels like just a hassle
(to me), and would rather have everything in one place so I can
change live and release ebuilds simultaneously as needed, plus not
have to sync metadata or eclass changes either (plus chiitoo has
::gentoo commit access now).
May move packages if I happen to work on them, albeit I have no
intention to really touch Qt5 or LXQt (anyone working on these
are free to the same if they want, or keep current workflow).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
