| Age | Commit message (Collapse) | Author |
|---|
|
Does not build without anymore due to some lacking guards
in tests, but it's not worth worrying with and may as well
require it (arguably this USE shouldn't even exist and be
hard enabled).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Seems to be lacking some guards against the other options,
but it doesn't really make sense for the ebuild to rely on
these and should just not pass when the main switch is off.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.9-2 -> 6.9-3 changes:
Updated:
- cstdint.patch (add a minor known missing include)
Likely still not final, but just a minor update before 6.9.0-rc.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Kind of forgot strip-flags no longer filters lto. Not that it was
*needed* given qt6-build.eclass filters lto either way but these
should be considered separate issues (aka, we may drop it from
qt6-build.eclass in the future but keep it in qtwebengine, or at
least when using gcc).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
9GB is "enough" but rather borderline (last build 8.9GB), and
may be a problem depending on USE+*FLAGS. Let's put it a 1GB
over to safe.
Also actually links with udev in 6.9+ now.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.9-1 -> 6.9-2 changes:
Removed:
* missing-prefinalizer.patch (upstreamed)
* no-vulkan-build.patch (upstreamed)
Plus rebasing where needed. This is due to Qt bumping baseline chromium
again in 6.9, it is now based on chromium-130.
This is still only preliminary updates just so patches applies and still
needs proper testing, will be checked using 6.9.0-rc when it releases.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
I see a change that is likely to prevent the race condition
issues, but not 100% sure.
cstdint.patch is upstreamed in >=6.9, still needed for 6.8.
6.9 newly needs nodejs[icu] or else it'll fail on some regex syntax
error (likely due to use of unicode bits in it). www-client/chromium
depends on nodejs[inspector] instead which itself depends on icu+ssl
(that we do need), but we do not seem to need inspector.
Also add [icu] to 6.8.9999 just-in-case, odds are won't be testing -icu
anymore and may miss something and no harm in having users set it for
6.8.3 before 6.9.0 drops
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Formerly left disabled given nothing in the tree needed it and it was
just an oddity, but some packages started to use it now (skanpage and
upcoming frescobaldi bump through pyqt6) and it is annoying to find
out that you need to rebuild qtwebengine to enable it.
It does add a bit to the compile time and size making it wasteful for
"most" users but it is ultimately kind of negligible in relation to
webengine itself.
Doing it live-only to spare a rebuild, will be for next bump.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Seeing distros that use system's ffmpeg (like Arch) hit obscure
issues while it works on Gentoo. Like some mp3 or opus files not
playing. In case of mp3, Qt had to do a workaround for system
ffmpeg to ensure it picks the right mp3 decoder given chromium
does not support the others. Opus case is unclear still.
If we ever switch to system (patched) ffmpeg (which would be nice
on paper esp. for binpkg due to USE=bindist), it should probably
use extra consideration and also be kept optional to debug.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.8-7 -> 6.9-1 changes:
Updated:
* missing-gn-deps.patch (partially upstreamed)
Removed:
* musl-lfs64-gn.patch (obsolete)
...plus rebasing where needed.
Just initial updates so patches apply again, has not been
really tested yet (esp. musl).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
May or may not have missed something due to there being a lot of
build system re-arranging making the diff noisy. Only picked up
that it no longer needs poppler for tests and that it now links
directly with libGLX with USE=opengl.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.8-6 -> 6.8-7 changes:
Added:
* gcc-ICE-workaround.patch (imported from files/)
* missing-prefinalizer.patch (bug #945808)
Hopefully no more patches for a while (at least none of
these needed revbumps).
Closes: https://bugs.gentoo.org/945808
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.8-5 -> 6.8-6 changes:
Added:
* missing-gn-deps.patch (imported from files/)
* no-vulkan-build.patch (bug #945766)
Intentionally keeping QTBUG-131156.patch in files/ for now, it's not
merged upstream yet (may not be final) and will be picked to 6.8 later
ultimately breaking 6.8.9999.
Closes: https://bugs.gentoo.org/945766
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.8-4 -> 6.8-5 changes:
Updated:
* gn-bootstrap.patch (partially upstreamed)
Not really tested yet, just so patches apply again.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Per the comment, already couldn't use system's libvpv when USE=vaapi
is enabled (this is intentionally enforced by the build system rather
than "broken"), and now USE=-vaapi fails to build in 6.8 with system's.
Seems like an easy fix but (even if fixed) feel it would be simpler
keep the same setup regardless of USE=vaapi until vaapi allows using
system's. I hardly test USE=-vaapi and missed that it broke, and I
assume this holds for upstream too.
qtwebengine does keep bundled libvpx either up to date or backports
security fixes, albeit bumps are less frequent and fixes could lag a
bit (not that we had a choice with USE=vaapi either way, unless drop
vaapi support).
As a small perk, it'll spare users from rebuilding qtwebengine on
libvpx subslot bumps which happen now and then.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.7-12 -> 6.7-13, and 6.8-3 -> 6.8-4 changes:
Updated:
* cstdint.patch (merged extra chunk from files/)
Dropped:
* clang19.patch (upstreamed)
* gcc15.patch (upstreamed)
Note:
6.8 patches are known to not apply right now, but that is because
they are made for the 6.8.0 branch (in preparation for release) while
the ebuild uses dev 6.8 which moved on to 6.8.1 and broke a patch.
Will update again sometime only after release is out of the way given
do not care to test 6.8.1 right now. Or earlier if the change is
backported to 6.8.0 in the interim.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Closes: https://bugs.gentoo.org/939519
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Not used anymore given patch was removed in favor of relying
on app-alternatives/ninja to select. NINJAFLAGS is still
recognized by a patch (not by ninja!).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Last build test for 6.8.9999 used exactly 8.0GiB, ebuild checks
for 8G but that's too borderline and should do +1
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.7-10 -> 6.7-11, and 6.8-2 -> 6.8-3 changes:
Added:
* clang19.patch (imported from files/)
* musl-no-settls.patch (wrt bug #937875)
6.7-10 -> 6.7-11 specific changes:
Added:
* QTBUG-113574.patch (imported from files/)
6.7-11 -> 6.7-12 changes (in preparation for 6.7.3):
Removed:
* ninja1.12.patch (upstreamed)
Technically needs a revbump for bug #937875 (runtime issue), but
do not wish for every users to rebuild over a musl fix. musl users
reading this are invited to `emerge -1 qtwebengine:6`. Stable users
are not believed to be affected, and there's to hope 6.7.3 releases
& is stabilized before musl-1.2.5 is (or a := forces a rebuild first).
Closes: https://bugs.gentoo.org/937875
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.7-9 -> 6.7-10 changes:
Added:
* gcc15.patch (with two fixes wrt bug #936415, built fine
with all USE enabled using gcc-15.0.0_pre20240721)
6.8-1 -> 6.8-2 changes:
Added:
* gcc15.patch (including an additional fix for 6.8+, untested)
Removed:
* ninja1.12.patch (upstreamed)
+ minor rebasing where needed
Closes: https://bugs.gentoo.org/936415
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Just realized the issue is self-inflicted. The pkg-config check
is done only if "use_pulseaudio && link_pulseaudio" and the latter
is passed by us rather than Qt.
It seemed harmless to be unconditional given the main switch
disabled it (which technically sounds better), but given it
doesn't for pdfium let's change that and do it for pipewire
as well while at it.
Bug: https://bugs.gentoo.org/934635
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Or hopefully anyway, have not tested the full build without libpulse,
but it at least no longer looks for it.
Unclear whether pdfium was automagically linking with it, or just
looking for it for nothing while unused. The former technically
needs a revbump, but not worth it given the long build times and
how pdfium is scarcely used.
Closes: https://bugs.gentoo.org/934635
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
While it is indeed included, odds are GL/glx.h is not truly
needed (included for nothing, does not link with libGLX nor
seem to dlopen it), may need review if manage to make X optional
in 6.8+ but is not important for now.
Untested whether it includes it even with USE=-opengl like
it does for some other GL headers, but leave it like that
for now (USE=opengl is mostly to control qt's dependency).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
* when built on non-desktop profile systems, the qtwebengine[opengl]
build fails because it needs GL/glx.h
Signed-off-by: Christopher Bayliss <cjbdev@icloud.com>
Closes: https://github.com/gentoo/gentoo/pull/37062
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.7-8 -> 6.7-9 changes:
Removed:
* flags.patch (tentative, commit 3373a27c to qt6-build.eclass
*should* make it unnecessary and gives us less to maintain --
does require re-adding symbol_level=0 Gn arg)
6.7-9 -> 6.8-1 has no changes beside rebasing with chromium-118
in preparation for adding 6.8.9999.
ninja-1.12.patch will likely be upstreamed before next releases
but kept for now given testing is annoying without it.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Unlikely to be missing, but seen a build-time check for these and
it would not hurt to be sure (does not link with these, have not
dug further but may be optional use with dlopen.
On a side-note, it may now be possible ot make X optional in
6.8+ -- not trying this is yet but will probably do before 6.8.0_rc
releases (keeping the safe status quo for now).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.7-7 -> 6.7-8 changes:
Removed:
* clang18.patch (upstreamed)
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
The has_version is not *necessary* but will make it easier to
know it's safe to drop when it becomes essentially a no-op.
Bug: https://bugs.gentoo.org/931623
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Bug: https://bugs.gentoo.org/931623
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Hoping it will be a short-lived and that this will be improved/fixed
in clang itself.
(have not tried nor looked at qtwebengine:5)
For some rough explanation from the little I get from this:
clang-18 added -mevex512 (missing from 17), and then -march=native
is a bit quirky in that unlike -march=exact it goes out of its way
to disable it resulting in e.g.
-march=skylake -mavx512f = -mevex512 is auto-enabled
-march=skylake -mevex512 = not "enabled" but can be used
-march=native(skylake) -mavx512f = forced off(!)
And then units that use avx512 / pass -mavx512f (for use with runtime
cpu detection) end in build failure without evex512.
Always passing -mevex512 on a machine without avx512 "seems" safe,
it does not even set __EVEX512__ and believe won't use any avx512
instructions on a whim (__EVEX512__ does get set if add -mavx512f).
Or at least my skylake (not skylake-x) passes test + can use the
qtwebengine built that way.
Considered passing only for files that need it at first with a patch
(sounded safer), but chromium's Gn files don't have a variable to test
clang version that I could see (or at least not in old qtwebengine) and
didn't want this to become more involved nor use conditional patching.
The !avx512 check may not be super necessary, but have not dug into
the implications of forcing it when avx512 is actually enabled (sounds
there are cases where it needs to be off, leaving it to compiler).
Bug: https://bugs.gentoo.org/931623
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Needs more looking into but want a quick workaround before 6.7.1
releases with clang users having started to use 18.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.7-6 -> 6.7-7 changes:
Added:
* clang18.patch (seems upstreaming will take some time still)
* ninja1.12.patch (partially imported from files/, half-upstreamed)
Updated:
* glx-headers.patch (drop upstreamed bit, merge files/'s displaykey)
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Missed that this is now always used in 6.7, *could* be skipped
by enabling minigbm but that is a intel-only alternative.
Not worth a revbump+rebuild given qtbase[gui] pulls libdrm either
way and unlikely for mesa to be missing.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
"May" be possible to do without, but configure.cmake has an
assert that prevents progressing if Quick+Qml is not found
(even if disabled qml components, not to say something else
may not genuinely need it), but for now hard depend on it.
In that context it may not be super worth keeping USE=qml,
albeit if unneeded it's still a bit less to build/install.
May revisit, but keeping is convenient for webchannel[qml?].
Skip revbump, not worth rebuilds and USE=widgets (default
and rarely disabled) is already pulling qtdeclarative.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.7-5 -> 6.7-6 changes:
Updated:
* x11-header.patch -> glx-headers.patch (updated for bug #928508)
Closes: https://bugs.gentoo.org/928508
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.6-9 -> 6.6-10 changes:
Added:
* clang18.patch (imported from files/)
Updated:
* cstdint.patch (for bug #928466)
6.7-4 -> 6.7-5 changes:
Added:
* x11-header.patch (imported from files/)
...not adding clang18 given expect it to be fixed upstream soon
Updated:
* cstdint.patch (for bug #928466)
...gcc+musl still untested for 6.7.0, but updating what's known
Closes: https://bugs.gentoo.org/928466
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
New with USE=webdriver. Originally thought it was just something
normal given the nature of webdriver (meant for testing) but now
noticed this is only created by tests/auto files.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Makes use of QT_CONFIG(accessibility) which can result in
undefined symbols if was enabled on qtbase then flipped off.
Like opengl/vulkan, this flag is typically enabled either
globally or not at all and should hopefully not cause conflicts
for most users.
Technically needed in non-live but given the low impact will
wait rather than let this trigger rebuilds which is not worth
it for qtwebengine.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
My llvm-musl test chroot did not keep gcc notably for finding
problems like this, and when I tried 6.7:
ld.lld: error: unable to find library -latomic
Have not dug further whether it's possible to be optional.
Thought it'd be with USE=-vulkan at first but no.
Not worth a revbump for 6.7.0_rc.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
They attempt to open display regardless and get a SIGTRAP ending
the entire test. If there is a display but it is still =offscreen,
the tests continue but with some normal failures instead. All good
with =xcb and a display.
Skip for now, albeit may consider virtx if it stays like that
(or if more tests start failing) given it's rather major tests.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
No deps but make it optional given most people do not need this
and it adds a bit of build time plus ~35MB to the install.
For the IUSE name, debated IUSE=webenginedriver as well but "webdriver"
is the name of the specification, and it felt redundant to have
webengine in the IUSE name for the webengine package.
wrt tests, unfortunately like most tools-related tests (see qttools),
it tries to use the system's tool and makes it difficult to specify
a path -- so skipping tst_webenginedriver for simplicity, it's not
a component that need to be overly worried about either way (haven't
tried but imagine may be further messy with sandbox too).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Fixes were merged bit at last minute and the bug for it (QTBUG-117979)
was updated late, and missed that 6.6.2 fixed py3.12 support.
Note that while it still has several references to distutils and an
upstream bug (QTBUG-115512), seems none are necessary as it built
fine with setuptools[-python_target_python3_12] after double-checking
that it did use 3.12.
(if reading this wondering why portage asks to rebuild qtwebengine,
it's time to start using -U/--changed-use rather than -N/--newuse --
alternatively could've held it back until 6.6.3 but well)
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.6-8 -> 6.6-9 and
6.7-3 -> 6.7-4 changes:
Updated:
* gn-bootstrap.patch (updated to not pass -Werror wrt bug #920758)
Removed:
* samurai.patch (unnecessary with the new app-alternatives/ninja)
Meant to do these last time updated patchsets, but forgot to read
my notes when worked on that. Doing it now so that it will be in
the 6.6.2 release in ~2 days.
Bug: https://bugs.gentoo.org/920758
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
