| Age | Commit message (Collapse) | Author |
|---|
|
Thought this was fixed, but had tested the wrong version.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.10-4 -> 6.10-[56]:
Removed:
- perfetto-pythonpath.patch (upstreamed)
Technically perfetto patch is only in the 6.10.0 branch and not 6.10
yet given the qtwebengine submodule has only been updated in one branch
but it'll most likely be soon or at least by the time of 6.10.1 (that
patch is only for a rare edge case either way).
6.10-5 (not used by any ebuild yet), is the same as 6.10-6 except
for a minor rebase needed due to a change that has made it in the
6.10 branch but not 6.10.0 and likely won't before release (so -5
will likely be used for 6.10.0-rc if nothing else comes up).
Also drop QTBUG-139424.patch from PATCHES, fixed upstream.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.10.0 branch still needs the old patchset at the moment (which is
the branch I used for the previous update in prepration for release),
this is for 6.10.1+.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.9-8 -> 6.9-9:
Added:
- clang21.patch (imported from files/)
- missing-includes.patch (bug #962555)
6.10-2 -> 6.10-3:
Added:
- clang21.patch (imported from files/)
Closes: https://bugs.gentoo.org/962555
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Upon closer look, openh264 seems unused with our current configuration
(both system's and bundled from a quick grep) and this just adds a
dependency or potential automagic for nothing.
Originally I thought it could be used with USE=bindist (no real reason
not to if system's), but it has configure.cmake checks to specifically
disable it when proprietary codecs are not enabled. Either way, the
code seems only for webrtc and wouldn't offer h264 playback with
bindist so the interest here was mostly to unbundle than functionality.
That aside, also noticed that some test junk was newly being installed,
(it's a whole QML libary so kind of annoying), and also that disk space
usage went over 10GB.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Unbundles openh264, only used if webengine_proprietary_codecs
is enabled meaning bindist not being set.
wrt SBOM, cmake files were failing to generate with it and haven't
spent more time on this (it'd likely work if had spdx-tools which
seems unpackaged, this is the fallback path) -- not super important
(for us) so let's just disable for now.
wrt new skipped test, this is a new test that fails only with one
of *-sandbox (haven't narrowed it down given it's tedious with
qtwebengine)
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.9-7 -> 6.9-8 and 6.10-1 -> 6.10-2 changes:
Added:
- perfetto-pythonpath.patch (bug #915615)
Bug: https://bugs.gentoo.org/915615
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Also cleanup xml REQ_USE, for 11..14 that USE is gone.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Minor changes from testing 6.9.9999 a bit in prepration for
6.9.2, haven't tested 6.10 again yet so required changes may
be incomplete there.
- gperf patch is upstreamed in 6.9.9999 too now
- workaround some new broken user_facing .txt, only tested
6.9.9999 but assuming 6.10/11 have the same problem right now
- tentatively drop the race condition workaround, a new
"DEPENDS WebEngineCore_sync_headers" has appeared in 6.9.9999 and
that may or may not be enough to make that obsolete but I have no
real way to test for sure, will re-add if we get reports
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Was still using 6.9's given chromium hadn't been updated yet, but
now it's based on chromium-134. No notable changes, just rebased.
Entirely untested, this is just so patches apply, odds are won't
test building/runtime (myself) until 6.10.0_rc.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
The 'CHROMIUM_VERSION' file lost its first empty line in commit
daab0b4ed7c, so the matching got dieded.
Signed-off-by: Jimi Huotari <chiitoo@gentoo.org>
|
|
On second thought, will set this in the eclass. Affects at least one
more package (qtmultimedia), and unused or replaced CMakeLists.txt is
a common trend in Qt and this may be volatile. If something breaks
with cmake-4, would rather that it just breaks rather than do the =3.5
workaround and will fix it then.
This reverts commit 73194358936565f89dcd99b29d74627cdbb99b0e.
Bug: https://bugs.gentoo.org/957476
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Was tempting to just set it in the eclass, but only two
packages it looks like.
Closes: https://bugs.gentoo.org/957476
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.9-{4,5} -> 6.9-{6,7} changes:
Updated:
- cstdint.patch (several more added for gcc-16)
May possibly be more missing for USE=-jumbo-build but have
not tried that.
Closes: https://bugs.gentoo.org/957200
Thanks-to: tdr
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.9-4 -> 6.9-5 changes:
Updated:
- gn-bootstrap.patch (drop NINJAFLAGS chunk)
While fixing an issue to conditionally pass -v to ninja, Qt
interestingly added support for the same env var (NINJAFLAGS)
that we were adding.
Unsure if upstream's support works right though (not tested), it
uses simple string replacement rather than separate_arguments().
Could imagine potentially causing issues if NINJAFLAGS had double
spaces inherited from users setting NINJAOPTS.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Closes: https://bugs.gentoo.org/955345
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Adapted from linked PR given hasn't been updated yet and wanted
to rebuild qtwebengine with the new dependencies on my llvm-musl
chroot now.
[atomic-builtins] is not enough given passes -latomic either way,
and not planning to try to get this fixed in chromium.
Also move to DEPEND-only, doesn't seem to be linked with shared
libatomic for gcc (and stub is static-only).
Skipping revbump given not worth rebuilds just to be able to
depclean gcc and qtwebengine-6.9.1 is not that far off. Besides
it's difficult to depclean given nodejs depends on it for libatomic
at the moment still.
Closes: https://github.com/gentoo/gentoo/pull/41689
Thanks-to: Michal Rostecki <vadorovsky@disroot.org>
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
On second thought, think would rather ensure that this is disabled
even if do not know how it happened in the first place, especially
given chromium itself relies on noexecstack rather than notes, but
then qtwebengine does not pass it for the final linking phase.
Believe this is only an issue for qtwebengine with its multitude
of asm files that may or may not be used, so not doing it in the
eclass.
Not revbumping given it seems to only happen in edge cases, but may
as well get this done before stable 6.8.3 so that if glibc-2.41 is
stabled later it'll ensure it's fine for them.
Closes: https://bugs.gentoo.org/953111
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.9-3 -> 6.9-4 changes:
Updated:
- musl-no-execinfo.patch
As usual only tend to test musl (+clang/libcxx) with .0 release
and there was one minor build failure due to a new execinfo-related
function not being guarded by #if/#endif.
Runtime also seems fine on llvm-musl, qutebrowser-9999 test pass
and can browse normally as well.
Still not including the other patches given they (hopefully)
shouldn't be that long lived.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Just so it's propagated when do bumps and reduce amount of revbumps
needed later (given qtwebengine is a huge package), it will be needed
whenever libxml2-2.14 is added & keyworded/unmasked with a new soname.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
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>
|
