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