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