| Age | Commit message (Collapse) | Author |
|---|
|
Using patchset-3 rather than -5 after all given seems the qtwebengine
submodule update hasn't been included in the -rc tarball despite being
in the 6.10.0 branch?
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>
|
|
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
Signed-off-by: Arthur Zamarin <arthurzam@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>
|
|
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>
|
|
Forgot that it needs an additional revert that wasn't in
6.9.2, else hits a build failure due to missing headers.
Also fix the commit link in the old patch.
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>
|
|
Untested given I do not have the required hardware to reproduce,
but doing this seems to have worked for Arch.
Closes: https://bugs.gentoo.org/962055
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Imagine Qt will backport from chromium as well and it'll conflict
later, but just to be sure it does not get forgotten.
Not touching stable 6.9.1, this will be stabilized long before
clang-21 is and haven't verified this all that closely.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Alfred Wingate <parona@protonmail.com>
Part-of: https://github.com/gentoo/gentoo/pull/43590
Closes: https://github.com/gentoo/gentoo/pull/43590
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
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>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Haven't really tested this one yet other than checking that
patches applies, which does not need a new patchset yet given
still based on chromium-130 like 6.9 is.
Signed-off-by: Ionen Wolkens <ionen@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>
|
|
Not the only issue, but this one is known exploited in the wild
giving it higher priority (rest will likely wait until Qt 6.9.2
like usual).
Bug: https://bugs.gentoo.org/957076
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>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Just to be in sync with other ebuilds and propagate to new users.
Skipping revbump is not "correct" but:
1. qtwebengine-6.9.1 is due soon (May 15 if not delayed), and won't
be masked unlike 6.9.0 (which already has :=)
2. assume new libxml2 won't be unmasked before then outside testing
3. for stable, 6.9.1 will likely be stabilized before new libxml2,
and then 6.8.2+6.8.3 will be removed from the tree.
For special cases, e.g. users unmasking for testing or using the
new libxml2 in stable, then can let preserved-rebuild do its thing
rather than make *everyone* do a very large rebuild for likely nothing.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Closes: https://bugs.gentoo.org/955345
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Closes: https://bugs.gentoo.org/925718
Signed-off-by: Andreas Sturmlechner <asturm@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>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
Signed-off-by: Arthur Zamarin <arthurzam@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>
|
|
Haven't reproduced the crash myself, but both falkon and
qutebrowser upstreams had reports about that issue with 6.9.0,
and may as well include it before potential unmasking.
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>
|
|
Also including backport for QTBUG-135047 (x11 pixmap leak) which
is fixed in 6.9.9999 but hasn't been included in the 6.9.0 release.
Not bothering putting it in the patchset given would need to make
new one for 6.9.9999 already.
The glibc-2.41 patch is also still not included, but it should
whenever 6.9.9999 gets a qtwebengine-chromium submodule update.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
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>
|
|
Same issue that chromium ran into wrt bug #951816
Bug: https://bugs.gentoo.org/951816
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Or probably clang-20 anyway, haven't confirmed that 19 works
for 6.8.3 (but definitely fine for 6.8.2, and the same bit of
code exists in it).
On that note, qtwebengine-6.8.2 is probably affected too, but
6.8.3 "should" be stabilized before clang-20 and it saves having
to test+change stable 6.8.2 for this.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
