www-client/epiphany: add 45.3

[MrRoy]

No description provided.

[gentoo-bot]

Pull Request assignment

Submitter: @MrRoy
Areas affected: ebuilds
Packages affected: www-client/epiphany

www-client/epiphany: @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

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-02-24 21:38 UTC
Newest commit scanned: 9adfe36
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/f1d79f1339/output.html

[pacho2]

It seems I am hitting a problem preventing me from fetching the latest git tree and test :/

but, I remember that this was blocked by some tests failing to pass on Gentoo:
https://gitlab.gnome.org/GNOME/epiphany/-/issues/2209

But I failed to find a proper fix for it... I don't know if others will find a real fix or we should simply skip the offending tests ...

[MrRoy]

@pacho2 for 44.8 I get two test failures, same as the ones you reported upstream:

Summary of Failures:

 5/14 Encodings test             FAIL            0.19s   killed by signal 6 SIGABRT
13/14 Web view test              FAIL            0.34s   killed by signal 5 SIGTRAP

However these tests are also failing for me on 44.6 which is already in tree.

But for 45.2/45.3, only one failure:

Summary of Failures:

13/14 Web view test              FAIL            0.33s   killed by signal 5 SIGTRAP

I don't know if others will find a real fix or we should simply skip the offending tests ...

Good question... I guess I could write a patch to remove this test completely.

[pacho2]

I would opt for skipping them, otherwise we will keep to have this test failing forever :s ,
even if it is sad that we couldn't find the real cause of bubblewrap having this conflicts with our sandbox system :/

I am not sure if maybe @leio could know?

Thanks!

[MrRoy]

@pacho2 I added a patch to exclude the failing tests
I also added the test dependencies since they are not present otherwise in the ebuild, however, it also needs media-libs/mesa[zink]. I tried to add that, but pkgcheck is failing with this error:

FAILURES
www-client/epiphany
  NonsolvableDepsInStable: version 44.8: nonsolvable depset(bdepend) keyword(~amd64) stable profile (default/linux/amd64/17.1) (87 total): solutions: [ media-libs/mesa[zink] ]

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-03-16 17:59 UTC
Newest commit scanned: bd1a65d
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/974ca7dc4a/output.html

[leio]

I have encodings failure on 44, which doesn't feel like has anything to do with bubblewrap or zink. I do get zink warnings, but these are just bogus warnings. Also the web view test failure, which does sound like bubblewrap might be involved. Maybe it is for the encodings too somehow? Haven't looked inside.
I don't think it's necessary to delay an ~arch bump for test failures that are there from before, albeit we should figure it out for next stabilization ideally. Not a big fan of skipping the tests when they ought to be fixable or runnable (e.g. by skipping bubblewrap via env var if it's indeed a bwrap + portage sandbox issue).

[MrRoy]

@leio @pacho2 so should I not drop the failing tests then? As in not include the patch & just let them fail?

[leio]

My vote is to keep it failing for the bump and to try to deal with it properly in a relevant bug (I think https://bugs.gentoo.org/847862 ?). But patch to skip it attached to the relevant bug for consideration if we can't fix it properly for next stabling. Help in fixing it fully much appreciated, or help in reaching a final conclusion that we just can't make it work for some reason and thus skipping will be right for the long term.

[leio]

I would also just drop 44.8 bump at this point and have only 45.x and update it there after saving the patch on the bug

[MrRoy]

@leio all done

[leio]

I have a dirty tree right now trying to finish up gstreamer-1.22 bump follow-ups and need to reserve the time to finish that before changing branches, etc. Hopefully @pacho2 can get to it sooner :)

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-03-19 22:08 UTC
Newest commit scanned: f628e6c
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/5b02073af9/output.html

[MrRoy]

I will update this PR to include epiphany 46.0, since Gnome 46 was released yesterday.
Edit: it depends on >=net-libs/webkit-gtk-2.43.4:6

[leio]

There are already 46 ebuilds available for that in another contributors tree I need to get to as well. I would consider concentrating on updating it to 45 here for fast-stabilization before the 46 lot goes stable much later.

[MrRoy]

@leio understood, then I will keep this PR for just 45.3 then.

[pacho2]

Thanks,

I wonder about dependencies not being updated to the requirements for 45.x version. I cannot download the latest tarball to confirm right now but, looking to other distros, it seems we need newer versions for some:
https://src.fedoraproject.org/rpms/epiphany/c/13e17e88bc1191c945fb9e38f1c97d30fd4e314a?branch=rawhide
https://src.fedoraproject.org/rpms/epiphany/c/94476cd242f68d312a7cd0ffc47b1cbba87e0964?branch=rawhide

Also, the dep on x11-base/xorg-server[xvfb] shouldn't be needed as virtualx.eclass should ensure it is properly pulled in

[MrRoy]

@pacho2 sorry about that, you are right. I checked only the release notes & linked PRs which didn't include any dependencies changes, but looking at meson.build, I see that it needed updates.

As a side note, for my personal knowledge, the updated dependency versions aren't in tree anymore anyway (the lowest available version in ::gentoo is higher than the requirement)
For example, gui-libs/gtk goes from 4.9.3 to 4.10.0, but lowest version in ::gentoo is 4.12.4
So in this case, why is it necessary to specify >=4.10.0? Could we not just put gui-libs/gtk with no regard for version?

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-03-25 23:54 UTC
Newest commit scanned: 596f0ef
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/6086ba71b9/output.html

[pacho2]

It is important to add the correct minimum version as we don't know what versions are available on every system. It will also indicate portage to update gtk to, at least, the minimum working version instead of trying to build against the outdated one (that could be found, for example, on a system not updated for some months).

[leio]

As a matter of Gentoo GNOME team policy and convention, the minimum deps in ebuilds are what are in upstream build system, except for the following cases (there may be more that I forget, using our best judgment):

• The project codebase has build-time optional support for a newer version (e.g. it makes use of something that is new API in gtk-4.12, but does so wrapped in GTK_CHECK_VERSION or similar in the code to still support older) - then if it makes sense (we have the newer packaged, etc), we ensure the new features are used by increasing the minimum accordingly
• There are known important bug fixes in the newer dependency version that are rather important for the app in question, then we could ensure a better working version and ideally also documented in the ebuild why it's raised to what the minimum is raised to
• The minimum version requirement is actually wrong in the build system and it needs increasing. This must (or a strong SHOULD) be accompanied with an appropriate upstream issue or merge request to fix it upstream as well, unless that's already pending upstream or fixed in git.

This is also to make comparing and validating them at bumps easier. This is also why the deps in ebuild are listed in the occurrence in the build system (meson.build), not some kind of artificial alphabetical order.

Otherwise, comparing the build system (such as meson.build) changes across version is the MAIN thing that a version bump in Gentoo really entails in terms of maintainer work.

[MrRoy]

I updated the dependencies last week but I just noticed that I forgot to remove the x11-base/xorg-server[xvfb] dependency. Should be good now

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-03-31 02:24 UTC
Newest commit scanned: 7199520
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/8b2b8a273a/output.html

[leio]

webkit-gtk dep was wrong - it's >= 2.41.1 in meson.build, not 2.41.0 as in ebuild. Also libadwaita, but that was fine and left it like you had on purpose (meson.build has >= 1.4.beta, so it could have been >=libadwaita-1.4_beta in ebuild)