net-libs/webkit-gtk: Version bump to 2.42.2

[bitlord]

No description provided.

[gentoo-bot]

Pull Request assignment

Submitter: @bitlord
Areas affected: ebuilds
Packages affected: net-libs/webkit-gtk

net-libs/webkit-gtk: @gentoo/gnome

Linked bugs

No bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment.

If you do not receive any reply to this pull request, please open or link a bug to attract the attention of maintainers.

---

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

[bitlord]

These are just copies of webkit-gtk-2.42.1* ebuilds, they build fine here using following flags:

net-libs/webkit-gtk-2.42.2-r600 X -aqua -avif -examples -gamepad gstreamer introspection jpeg2k -jpegxl jumbo-build keyring lcms pdf seccomp spell systemd wayland
net-libs/webkit-gtk-2.42.2-r410 X -aqua -avif -examples -gamepad gstreamer introspection jpeg2k -jpegxl jumbo-build keyring lcms pdf seccomp spell systemd wayland
net-libs/webkit-gtk-2.42.2 X -aqua -avif -examples -gamepad gstreamer introspection jpeg2k -jpegxl jumbo-build keyring lcms pdf seccomp spell systemd wayland

Regarding patch files/2.42.1-arm64-non-jumbo-fix.patch this doesn't seem to be applied upstream yet, applies fine here, but haven't renamed/copied it, not sure should we re-use this one even if it's named after previous release?

I'm only using net-libs/webkit-gtk-2.42.2-r{410,600}, so I didn't tested net-libs/webkit-gtk-2.42.2, except that it builds.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2023-11-11 02:06 UTC
Newest commit scanned: ebe59d1
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/457495f47b/output.html

[bitlord]

Fixed KEYWORDS, forgot to reset, sorry!

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2023-11-13 18:41 UTC
Newest commit scanned: f63cc09
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/9582339605/output.html

[orlitzky]

This is a security release (they pretty much all are):

https://www.openwall.com/lists/oss-security/2023/11/15/1

And can we please take this entry out of base/package.use.force while we're at it? (https://bugs.gentoo.org/914362#c26):

# Matt Turner <mattst88@gentoo.org> (2023-09-18)                                                                                                                             
# Disabling gstreamer seems to be untested upstream and is often broken.                                                                                                     
# The gstreamer dependencies are trivial in compile time and disk usage                                                                                                      
# compared to webkit-gtk.                                                                                                                                                    
# Bugs #911663, #914362                                                                                                                                                      
>=net-libs/webkit-gtk-2.42 gstreamer

[orlitzky]

Can I merge this? The updates are trivial and it fixes arbitrary code execution on the web and probably also in evolution. I'm building with USE=gstreamer enabled to make sure that works, too. It should be done by tonight.

[leio]

You need to test with gstreamer disabled, not enabled, in regards to the package.use.force - that forces it to always be enabled otherwise.
USE=-jumbo-build fix patch should be retained as well if it's still necessary for a successful build, which is likely if the patch still applies, and iirc that was only broken on arm64.
It is common to keep using patches versioned after the previous version if it still applies. modifying $PV to the version in the patch name in the process in the ebuild.

[orlitzky]

You need to test with gstreamer disabled, not enabled, in regards to the package.use.force

Whenever I say the opposite of what makes sense please just assume that I said the opposite of what I said :)

This version builds and runs fine without gstreamer.

[leio]

Though to remove the entry, all remaining versions ought to build fine without it - or we need to version limit the restriction to the older versions and eventually clean it up as the old versions are gone naturally.

You can merge the ebuild side, if the diff with the previous version for each revision is only changing of $PV to 2.42.1 in the jumbo patch line - if something else, would be good to check the diff over.

[orlitzky]

Done!

Though to remove the entry, all remaining versions ought to build fine without it - or we need to version limit the restriction to the older versions and eventually clean it up as the old versions are gone naturally.

I changed it to <2.42 because I've only tested 2.42.1 and 2.42.2.

You can merge the ebuild side, if the diff with the previous version for each revision is only changing of $PV to 2.42.1 in the jumbo patch line - if something else, would be good to check the diff over.

The only diff between the versions is the ~arch keywords.