Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 893234 - dev-qt/qtwebengine on x86 and arm
Summary: dev-qt/qtwebengine on x86 and arm
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords: PullRequest
Depends on:
Blocks:
 
Reported: 2023-02-04 18:53 UTC by Andreas Sturmlechner
Modified: 2024-03-23 17:01 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Sturmlechner gentoo-dev 2023-02-04 18:53:54 UTC
In a chat some time ago...

> [20:24] <arthurzam> asturm: sam_: I wanted to ask your thoughts on 
>         de-stabilize KDE parts on x86, for example www-client/falkon
> [20:25] <arthurzam> I suspect too many packages have stable x86 
>         because it has stable amd64, not because it is relevant
> [20:31] <ionen> suspect will have to remove x86 from falkon entirely 
>         at some point, it'll eventually migrate to qtwebengine:6 
>         which last I know of is unlikely to work on x86
> [20:40] <ionen> not that I've been following this
> [...]
> [21:59] <asturm> arthurzam: well, what would be the reason (re 
>         falkon)?
> [22:00] <asturm> does qtwebengine not build on x86?
So, let's clarify here what the problems are and take action afterwards.

I suspect the above is about issues with building qtwebengine on *actual* x86 hardware as opposed to amd64 in a 32-bit chroot. I can't help but notice also that x86 stabilisations are delayed when qtwebengine revdeps are involved (see bug 884137, bug 888203).

The suggestion in the above IRC snippet was to de-stabilise qtwebengine:5 revdeps. But then I am wondering, if the issue is building on that hardware, what good is it to even keep it in ~x86? dev-qt/qtwebengine:6 has that already settled as chromium dropped ~x86 keyword quite some time ago.

So, do we
a) de-stabilise dev-qt/qtwebengine:5 +revdeps on x86
b) package.use.mask dev-qt/qtwebengine:5 +revdeps on x86
c) completely drop dev-qt/qtwebengine:5 +revdeps on x86
?
Comment 1 Andreas Sturmlechner gentoo-dev 2023-02-05 14:29:04 UTC
If I am not mistaken we can basically look at amd64/x32 for what would be necessary:

package.use.mask:
> app-i18n/fcitx-libpinyin dictionary-manager
> dev-lang/idris2 test-full
> dev-python/cloudscraper test
> games-util/lgogdownloader gui
> kde-apps/kde-apps-meta:5 pim
> kde-apps/kdenetwork-meta:5 bittorrent telepathy
> kde-apps/kleopatra:5 pim
> kde-apps/umbrello:5 php
> kde-misc/kio-gdrive share
> net-irc/quassel urlpreview
> net-misc/fatrat bittorrent
> net-misc/seafile-client shibboleth
> sci-mathematics/yacas gui
> sci-physics/root qt5
use.mask:
> webengine
package.mask:
> dev-qt/qtwebengine
> dev-qt/qtwebview
> dev-python/PyQt6-WebEngine
> dev-python/PyQtWebEngine
> app-admin/calamares
> app-doc/zeal
> app-editors/ghostwriter
> app-editors/notepadqq
> app-editors/retext
> app-misc/anki
> app-office/kalendar:5
> app-office/kmymoney:5
> app-office/skrooge:5
> app-office/texmaker
> app-text/bibletime
> app-text/calibre
> app-text/cb2bib
> app-text/kchmviewer
> app-text/sigil
> dev-lang/typescript
> dev-python/spyder
> dev-python/spyder-terminal
> dev-python/spyder-unittest
> dev-python/spyder-line-profiler
> dev-python/spyder-vim
> dev-python/spyder-notebook
> dev-util/kdevelop:5
> dev-util/kdevelop-php:5
> dev-util/kdevelop-python:5
> gnome-extra/gnome-shell-extension-pop-shell
> kde-apps/akonadi-calendar:5
> kde-apps/akonadi-import-wizard:5
> kde-apps/akonadiconsole:5
> kde-apps/akregator:5
> kde-apps/calendarjanitor:5
> kde-apps/calendarsupport:5
> kde-apps/cantor:5
> kde-apps/eventviews:5
> kde-apps/grantlee-editor:5
> kde-apps/incidenceeditor:5
> kde-apps/kaccounts-providers:5
> kde-apps/kaddressbook:5
> kde-apps/kalarm:5
> kde-apps/kalgebra:5
> kde-apps/kdepim-addons:5
> kde-apps/kdepim-meta:5
> kde-apps/kdepim-runtime:5
> kde-apps/kimagemapeditor:5
> kde-apps/kmail:5
> kde-apps/kmail-account-wizard:5
> kde-apps/kmailtransport:5
> kde-apps/knotes:5
> kde-apps/konqueror:5
> kde-apps/konsolekalendar:5
> kde-apps/kontact:5
> kde-apps/korganizer:5
> kde-apps/ktp-accounts-kcm:5
> kde-apps/ktp-text-ui:5
> kde-apps/libksieve:5
> kde-apps/mailcommon:5
> kde-apps/messagelib:5
> kde-apps/mbox-importer:5
> kde-apps/parley:5
> kde-apps/pim-data-exporter:5
> kde-apps/pim-sieve-editor:5
> kde-apps/plasma-telepathy-meta:5
> >=kde-misc/kio-gdrive-22.04.3-r1
> kde-misc/tellico:5
> kde-misc/zanshin:5
> mail-client/kube
> media-gfx/digikam:5
> media-gfx/luminance-hdr
> media-sound/frescobaldi
> media-sound/teamspeak-client:3
> >=media-video/openshot-2.6.0
> media-video/vidify
> media-video/vidify-audiosync
> net-analyzer/nmapsi
> net-libs/signon-ui
> net-misc/nextcloud-client
> net-p2p/ktorrent:5
> sci-geosciences/qmapshack
> sci-mathematics/rkward:5
> sci-visualization/labplot:5
> sys-apps/polychromatic
> www-client/falkon
> www-client/otter
> www-client/qutebrowser
> media-video/jellyfin-media-player
Comment 2 Arthur Zamarin archtester Gentoo Infrastructure gentoo-dev Security 2023-02-05 19:18:40 UTC
I will try to explain my thoughts.

I think x86 as a stable arch is long overdue. It seems like we don't have an active userbase of true x86, and I suspect all of them use it as headless, where KDE/Gnome are quite irrelevant. This is a gut feeling and I've no proofs.

In the idea that x86 stabilization takes non-trivial time and power, and our only devbox for x86 is for amd64, which has a lot of load (because of stabilizing for amd64), I do prefer to lessen it somewhat by starting to stop stable x86 from a lot of packages.

We've been adding x86 for any package that has amd64 for a long time (I think we stopped auto starting with "~amd64 ~x86" only around a year ago) we have a huge amount of stable x86 packages which I suspect we don't really need.

I also want to note that looking at "Arch testing dashboard", x86 is at the worst state [1]. (I measure it by amount of pending work, but also the amount we process, as for {arm,ppc}{,64} we process a lot of requests)

Which is why I thought to start with the more active project, KDE/Qt. I think we can start by back to ~x86 all the tree depending on qtwebengine, and then maybe full kde & qt. Then we can try to also drop to ~x86 all Gnome/gtk stuff.

Do note that it is just my feeling as arch tester, and I'm not the AT lead, council, QA team or anything of that sort - just a helper that raised the idea to break the status-quo.

[1] https://dev.gentoo.org/~arthurzam/at_bugs_report.html
Comment 3 Andreas Sturmlechner gentoo-dev 2023-02-05 19:26:35 UTC
Allan Sandfeld Jensen added a comment - 29 Jun '21 10:16
> We had that requirement for Qt5 too, were you using distro patched sources?
> 
> Note, while you could in theory build on a 32bit host, you could only build
> the release binaries, and only if you are lucky since linking uses 8-20Gbyte
> of memory.
Allan Sandfeld Jensen added a comment - 29 Jun '21 10:17
> And note we can still build for x86 arm and mips, just not on x86, arm and 
> mips. The host needs to be 64bit due to memory requirements while linking.
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-02-05 19:33:38 UTC
arthur's comment sums it up quite well. I think we have a lot of debt for x86 where we're stabling things for the sake of it, and some devs are still automatically adding it on new packages (+ stablereqs). We should write something to gentoo-dev about not doing that (unless we did already and I forgot about it).

There's two things in conflict for me here:
1. I think not being able to build on $X is a good reason for it to not be marked stable on $X
2. Not being stable on $X means we test it less frequently and are less likely to spot problems. But being honest, if I have time to spend on 32-bit platforms, I'd rather not spend it on something like qtwebengine anyway.

Stable-masking it gives us a chance to explain why and also avoids users trying to build it and getting
a poor experience. Those who are able to handle binpkgs and set them up should be able to overcome that
without being too confused.
Comment 5 Davide Pesavento gentoo-dev 2023-02-05 21:24:38 UTC
(In reply to Sam James from comment #4)
> arthur's comment sums it up quite well. I think we have a lot of debt for
> x86 where we're stabling things for the sake of it, and some devs are still
> automatically adding it on new packages (+ stablereqs). We should write
> something to gentoo-dev about not doing that (unless we did already and I
> forgot about it).

+1
Comment 6 Andreas Sturmlechner gentoo-dev 2023-02-07 10:41:50 UTC
Done.
Comment 7 Andreas Sturmlechner gentoo-dev 2023-02-07 16:26:50 UTC
Re-opening for ~arm. We have 3 build failure bugs (see "see also" in bug 636242) filed against dev-qt/qtwebengine that look quite fundamental.

Can we assume no one has really built dev-qt/qtwebengine on ~arm in years, and should we de-keyword it right away?
Comment 8 Larry the Git Cow gentoo-dev 2023-02-07 16:33:14 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f572a09a0be05cfec6f53c4c4fc34416af768f82

commit f572a09a0be05cfec6f53c4c4fc34416af768f82
Author:     Andreas Sturmlechner <asturm@gentoo.org>
AuthorDate: 2023-02-07 16:31:48 +0000
Commit:     Andreas Sturmlechner <asturm@gentoo.org>
CommitDate: 2023-02-07 16:33:01 +0000

    profiles: arm: Cleanup obsolete kde-plasma/* webengine package.use.mask
    
    Replaced by arm-wide webengine use.mask.
    
    Bug: https://bugs.gentoo.org/893234
    Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>

 profiles/arch/arm/package.use.mask | 9 ---------
 1 file changed, 9 deletions(-)
Comment 9 Andreas K. Hüttel archtester gentoo-dev 2023-04-08 13:29:05 UTC
Looks like everything is done here for now.
Comment 10 Larry the Git Cow gentoo-dev 2024-03-23 17:01:00 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=515f4ac4feb7922005b4d4de7edb531a2658c12d

commit 515f4ac4feb7922005b4d4de7edb531a2658c12d
Author:     Andreas Sturmlechner <asturm@gentoo.org>
AuthorDate: 2024-03-23 12:36:28 +0000
Commit:     Andreas Sturmlechner <asturm@gentoo.org>
CommitDate: 2024-03-23 16:59:44 +0000

    dev-qt/qtwebview: 5.15.13 version bump, unkeywording ~arm/~ppc64
    
    Bug: https://bugs.gentoo.org/893234
    Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>

 dev-qt/qtwebview/Manifest                 |  1 +
 dev-qt/qtwebview/qtwebview-5.15.13.ebuild | 22 ++++++++++++++++++++++
 2 files changed, 23 insertions(+)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e50e0290feb058519b96767bc8cf903b6715a60e

commit e50e0290feb058519b96767bc8cf903b6715a60e
Author:     Andreas Sturmlechner <asturm@gentoo.org>
AuthorDate: 2024-03-23 12:34:45 +0000
Commit:     Andreas Sturmlechner <asturm@gentoo.org>
CommitDate: 2024-03-23 16:59:44 +0000

    dev-qt/qtwebengine: 5.15.13 version bump, unkeywording ~arm/~ppc64
    
    Bug: https://bugs.gentoo.org/893234
    Bug: https://bugs.gentoo.org/924936
    Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>

 dev-qt/qtwebengine/Manifest                        |   2 +
 .../qtwebengine-5.15.13_p20240322.ebuild           | 244 +++++++++++++++++++++
 2 files changed, 246 insertions(+)