| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
