| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
While this currently still requires X11 dependencies,
qtbase[X] itself should not be necessary.
Sparing the revbump.
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>
|
|
Essentially a rewrite, so only have a not exhaustive summary
of changes rather than split commits.
Bugs addressed:
* respect *FLAGS wrt bug #652172 (fwics should be no issues left)
* hopefully fixed musl/libcxx (tested with llvm-musl) wrt bug #876520
(not planning to review Qt5's myself, so no changes on that end)
IUSE changes:
* enable alsa by default, finding that you have no audio options
only after building is not great and alsa is cheap
* enable widgets by default, needed by both falkon and qutebrowser
* add custom-cflags, if going to use *FLAGS then should strip-flags
like chromium's ebuild
* add opengl, unfortunately littered in QT_CONFIG(opengl) and need
qtbase[opengl=] to avoid ABI/automagic issues
* add vulkan, has its own feature so should only need qtbase[vulkan?]
* add qml similarly to other packages
Misc:
* support EXTRA_GN like qtwebengine:5 and chromium (Gentoo-specific)
* build dir went from >9GB to ~6.3GB by dropping -g1
* drop estack+extglob, setting extglob is technically not needed for
use in bash [[ ]] tests which is-flagq does
* drop INCLUDEPATH, tried to sed qmake files but this is using cmake
* respect NINJA env var to allow samu (NINJA_PATH was a no-op)
* use get_NINJAOPTS for NINJAFLAGS and ignore environment (NINJAOPTS
is the var to set for this, while NINJAFLAGS is a private
qtwebengine var, ninja does not actually use this directly)
* drop icu's bundling check for simplicity (and consistency with other
system libraries), bug #630834 prompted adding this but does not
seem so fragile anymore (plus iwdevtools would report lib misuse,
albeit not headers)
* switch to bundled re2 to be spared headaches (see github PR#32281)
* optfeature on chrome-binary-plugins for widevine support
* cleanup/reduce QT_FEATURE and old comments
* fix designer automagic
* various dependencies adjustments, wrt re2c that is only needed if
we build ninja
* do not redefine _FORTIFY_SOURCE (use gentoo's defaults), upstream
actually switched to =3 in chromium-118 (albeit only for ChromeOS)
and "hopefully" is fine for this older version (tests pass at least)
Also moved patches to a tarball (like qt5). It is simple small patches
mostly adjusting macros rather than add actual code, but was beginning
to add up.
Considered reducing RAM requirements a little bit (generally *seems*
not so bad), but there is rather bad spikes and I do not think it can
be considered safe unless we assume everyone is not using RAM for
anything else. Plus usage will likely keep growing with versions.
Bug: https://bugs.gentoo.org/652172
Bug: https://bugs.gentoo.org/876520
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Just an unnecessary disparity between ebuilds to maintain, plus
would typically be inaccurate in live ebuilds (albeit check may
make live version fail on a whim if format changes, but kept
fatal or else issues will be easy to miss on bumps).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
qtwebengine handling of gn does not allow to use CBUILD toolchain,
and only when cross-compiling it will look for system's. Also does
not respect *FLAGS as upstream intentially commented these out
because someone did a bug report with overzealous flags (QTBUG-64759).
And, unfortunately, qtwebengine's is modified and so dev-util/gn
may not work as expected with it (plus will need CMakeLists
modifications to be found).
Bare that, two possible options would be:
1. dev-qt/qtwebengine-gn or so to BDEPEND on and build cleanly
2. fix the mess that is the modified gen.py, and use BUILD_ variables
For now at least skip installing it as it'll just cause conflicts
if we want to do this later and is not really useful unless
want to do something like BDEPEND="cross? ( dev-qt/qtwebengine )".
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Allows dropping a workaround in qutebrowser. And yes, wrt -w, the line
we are changing literally has "Gentoo" in an upstream comment.
Also move qt6-build_src_prepare up given modifying files before
patches tend to be messy.
No revbump given use case is rather uncommon.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
ebuild needs more real refactoring (will do in a separate revbump),
but at least address pkgcheck's warnings in this one
wrt src_unpack (which triggers indirect git-r3 usage), not quite
sure what the debug check was doing (repeated) there, and (currently)
no patchset to unpack so can just drop the whole thing. For patchsets
this may be better handled in qt6-build given it is the one inheriting
git-r3.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
* use -j1 (similarly to when I tried to use python-xdist on
qutebrowser which uses qtwebengine, parallel tests don't
seem to work so well here either)
* skip tests that need network
* skip cert test, not looked too closely but likely missing
something or (maybe) expirations are causing issues
* export various variables to stop it from using the system's
qtwebengine (otherwise fails if not installed)
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>
|
