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