| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
6.6-7 -> 6.6-8 and
6.7-2 -> 6.7-3 changes:
Removed:
* icu74.patch (upstreamed)
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Unknown if this really helps, depend on if the file was missing
or if it was just failing to find where it is with bad include
search -- but given it is generated good odds it is the former.
Have not actually reproduced myself and it is possible another
target also needs to be run, could potentially fail differently
if that does not resolve it (forcing -j1 is of course out of the
question for this package).
Needs a proper investigation/fix, but given this tend to fail
very late in the build it is not obvious and ccache likely makes
it harder to fail. Does not help that these rules are created
through several Qt cmake wrapper functions (the sync headers
bits come from qtbase cmake files, not from here).
May tentatively try to remove in a somewhat-distant future to see
if it is still an issue, and/or when related-sounding fixes occurred
in qtbase or qtwebengine.
Closes: https://bugs.gentoo.org/915953
Closes: https://bugs.gentoo.org/921680
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
This reverts commit b179a17a6695decb63e3bb7c824a9766b69cf7aa.
Hadn't noticed this had been done for lex as well. Like bison, this
looks for flex directly like bison and does not respect LEX.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
The check was removed before I touched these and didn't know it
existed. Was fair to think it wouldn't be needed anymore with cmake
but it is, e.g. it installs nothing if bison is not found without
hard failure.
File path is hopefully correct for Qt6, did give it two test builds
(one "bad" that's empty, and one full build) just in case. Albeit
haven't retried prefix (it's included in QT6_LIBDIR though).
The qt6-build eclass does force fatal errors for a few "build nothing"
cases, but not qtwebengine's custom ones. Kind of wonder if a similar
end result file check should be done for all of dev-qt/* (aka fail if
does not install anything but cmake files and docs). May revisit if Qt
has more original ways to build nothing not limited to qtwebengine.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
This reverts commit 2e783c9f85e7259aaabc02dbc7175ffb2313f3db.
This may not set YACC, but that's because qtwebengine does not respect
this variable in the first place and looks for bison directly.
This furthermore fails in a horrible way, it installs an empty
qtwebengine when bison is not found (should probably improve this
to hard fail).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
All of these will be using app-alternatives/yacc anyway as they're not unsetting
YACC or LEX, so make the dep reflect reality.
(Included both YACC and LEX out of conservatism.)
Signed-off-by: Sam James <sam@gentoo.org>
|
|
All of these will be using app-alternatives/lex anyway as they're not unsetting
YACC or LEX, so make the dep reflect reality.
(Included both YACC and LEX out of conservatism.)
Signed-off-by: Sam James <sam@gentoo.org>
|
|
6.6-5 -> 6.6-6 changes (only used by 6.6.1):
Added:
* gcc14.patch (imported from gentoo tree, not needed in 6.7)
Updated:
* cstdint.patch (>=qtwebengine-6.6.1 needs an extra for gcc+musl)
6.6-6 -> 6.6-7 changes (due for 6.6.2 if nothing else comes up):
Removed:
* libcxx17.patch (backported from 6.7)
* libxml2-2.12.patch (upstreamed)
6.7-1 -> 6.7-2 changes (tentative, release is still far away):
Updated:
* cstdint.patch (>=qtwebengine-6.6.1 needs an extra for gcc+musl)
Removed:
* libxml2-2.12.patch (upstreamed)
Safe changes, and no need for revbumps.
For libxml2, Qt did the same changes that we did rather than do
like upstream chromium. Meaning we do not need to depend on the
newer libxml2 and it works for the old as well.
Hopefully more gcc+musl issues don't keep showing up given been using
clang+musl for testing musl and would rather not do both on top of
gcc+glibc (idea was to pickup most toolchain issues with only two
builds). Only know about this because a user mentioned it on IRC.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Bit like Qt5's webengine which did not respect it either. Not ideal
but given the complexity tend to be lucky if it builds at all.
As noted in the comment, please report if this works again so can
cleanup (can test with USE=custom-cflags), may get fixed either
by >=qtwebengine-6.7 (chromium-118) or a new gcc version depending
on where the real issue is, but not planning to pursue this further
myself.
Closes: https://bugs.gentoo.org/920555
Closes: https://bugs.gentoo.org/920568
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
This is chromium 112->118 and is unsurprisingly going up.
May be a bit less with USE=-pdfium but margin won't hurt.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.6-5 -> 6.7-1 changes:
Removed:
* musl-no-close.patch (QT's fork now always disables that nonsense)
* libcxx17.patch (upstreamed)
Plus some rebasing where needed.
Still subject to changes given testing is still minimal and
have notably not tried 6.7+ with musl yet.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Adds a system-gbm option but it was already default ON and
changes nothing given we do not need to turn it off.
This is also still only used with screencast/vaapi, and gn
now complaints that the option that Qt's build system passes
was unused if disabled (thankfully not fatal).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.6-4 -> 6.6-5 changes:
Added:
* icu74.patch (imported from filesdir)
* libxml2-2.12.patch (imported from filesdir)
Imagine may be fixed in 6.6.2, but add just to allow cleaning
these up later given 6.6.1 is a stable candidate while others
are due to be dropped.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Thought hit a 6.6.1 regression while using 6.6.9999 after had rebuilt
the qt stack without tests, but turns out qtbase[test] vs [-test] seems
to affect this test.
Given most people running tests with qtwebengine likely enable for the
rest of the qt stack, seems went overlooked.
Failure itself is trivial, it is likely the test being performed badly
(fake touch and hold text selection event) rather than an actual
runtime problem. Let's just skip for now to avoid issues when attempt
to keyword this by itself.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Seeing little reason to lack support or make it optional given
need using v8 for webengine either way.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Just so use of the word does not get outdated.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
In preparation for approaching 6.6.1 release.
6.6-3 -> 6.6-4 changes:
Removed:
* ffmpeg-binutils-2.41.patch (upstreamed)
* libvpx-CVE-2023-5217.patch (upstreamed)
Not adding icu74 patch, still waiting to see how it goes
upstream (should be hopefully short lived either way).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Newly does a dns-over-https test.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
In QTBUG-115722, Qt opted to disable vaapi autodetection if
QT_FEATURE_vulkan is disabled due to missing headers, but can ignore
that and just pull the headers (not used without webengine_vulkan).
Ideally would just depend on vulkan-headers regardless of vaapi,
but it is not used in other parts of qtwebengine (it bundles like
3-4 different copies of vulkan-headers and for some reason wants
the system's here).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Turns out -g is still too much, or at least with gcc+bfd.
Closes: https://bugs.gentoo.org/914475
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
On second thought let's do this, but keep a warning that mentions
USE=custom-cflags given users may not be used to -g* getting
replaced and then lacking the symbols they were expecting.
Not going to keep disk space / memory usage updated for -g as
estimates would likely be all over the place and consider that
the warning is sufficient there.
Not using a full replace-flags '-g*' -g to allow e.g. a package.env
that adds -g0/-g1 at the end to still work while disregaring the
warning without implementing extra logic.
Note that have not retried -g to be sure it is fine, albeit pretty
sure it was fine last time tried. Worst case could replace by -g1,
or drop flags-respecting-patches and request debugging symbols to
gn instead (selectively forces -g1 even if asked for more).
Closes: https://bugs.gentoo.org/914475
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
If this comes up more often an issue, may opt to transform -g*
(other than -g0) for -g without USE=custom-cflags. Albeit do
not overly want to give surprises, nor assume when something
is going to work or not given the toolchain and other options.
Note that this does not affect <qtwebengine-6.5.2-r1 nor
qtwebengine:5 because they simply do not respect *FLAGS.
Bug: https://bugs.gentoo.org/914475
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Still keep := though, ensures that remain compatible
with the library that gets opened.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.5-1 -> 6.6-1 changes:
Added:
* libcxx17.patch (import from 6.5.2 ebuild)
* screencast-gio.patch (regression fix backported from 6.7)
Updated:
* musl-no-execinfo.patch (reduced, mostly fixed upstream)
* musl-no-res-ninit.patch (reduced, mostly fixed upstream)
Removed (fixed upstream):
* musl-lfs64.patch
* musl-no-canonicalize.patch
* musl-no-temp-retry.patch
* musl-no-user-vfp.patch
* musl-pthread-stack.patch
* musl-stacksize.patch
* musl-stdint.patch
* musl-systypes.patch
* narrowing-cast.patch
Still a way to go before release, so may still need updates.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
wrt [X], it currently auto-uses va_x11.h if ozone x11 is enabled,
it *could* be optional (use_vaapi_x11) but it probably makes little
sense to introduce IUSE=X unless we can make ozone_x11 optional too.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Upstream has unbundled by default.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
This is in part a message to future revdeps that having their
own USE=pdf will not work too well given it is default on
desktop profile and we do not really want to pull webengine
by default unless really wanted. Plus gives a way to disable
globally for arches where qtwebengine is not keyworded.
At worst this will become innacurate if qtpdf changes its
backing library.
IUSE is still in live-only so should not really disrupt.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Nothing seems too special here, so can just enable it.
Live-only given IUSE=pdf is a default on desktop profiles and will
cause a big unnecessary rebuild (nothing needs QtPdf yet). Note
that QtPdf is fairly trivial (and small'ish) after chromium bits
are already built either way, and does not hurt as a default.
Does require cups at build time (dlopen, left DEPEND-only). May be
possible to be optional but would rather no pdf-only IUSE=cups on
this big package (may revisit if someone wants this).
Would be nicer split (or allow IUSE=-webengine) but, even though the
option exists, build system files note that webengine cannot really
be disabled and then QtPdf still needs parts of chromium to be built
(splitting would cause to rebuild some of the same things twice, but
it is not nearly as big as webengine proper). May revisit.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
