I'm new to this port and I'm looking for a roadmap to update it. At the moment: -gtk3 is using 4.0 API -gtk4 is using 5.0 API - Flavorize dealing with 4.0, 4.1 and 6.0 APIs Inspired in OpenBSD port 2.42.4 ### www/webkitgtk4/Makefile ### FLAVORS = webkitgtk41 webkitgtk60 FLAVOR ?= .if ${FLAVOR:Mwebkitgtk41} API = 4.1 WANTLIB += atk-1.0 gdk-3 gtk-3 soup-3.0 LIB_DEPENDS += devel/libsoup3 \ x11/gtk+3 CONFIGURE_ARGS += -DUSE_SOUP2=OFF \ -DENABLE_WEBDRIVER=OFF .elif ${FLAVOR:Mwebkitgtk60} API = 6.0 WANTLIB += graphene-1.0 gtk-4 soup-3.0 LIB_DEPENDS += devel/libsoup3 \ x11/gtk+4 CONFIGURE_ARGS += -DUSE_SOUP2=OFF \ -DUSE_GTK4=ON .else API = 4.0 WANTLIB += atk-1.0 gdk-3 gtk-3 soup-2.4 LIB_DEPENDS += devel/libsoup \ x11/gtk+3 CONFIGURE_ARGS += -DUSE_SOUP2=ON \ -DENABLE_WEBDRIVER=OFF .endif ### My first question is: Why isn't 5.0 included in OpenBSD port? Does 5.0 was superceded by 6.0? Looking at this flavors, old and new software can pick API needed to work. Thoughts are welcome.
4.0 and 4.1 SONAMEs are both GTK3, the only difference is the libsoup used. Only 4.0 uses libsoup (2), all others use libsoup3. Been a minute since I've looked at the GTK4 SONAMEs but last I checked it was 5.0. Not sure what constitutes 6.0 yet. The bigger issue wrt flavourisation is packaging the documentation.
Quick glance later, SONAME 6.0 supersedes 5.0 entirely.
It is clearer now, the best way to proceed will be working on both ports as it is now: -gtk3: update and deal with 4.0 and 4.1 SONAMEs -gtk4: update and deal with 6.0 SONAME
I'm working on this update [1], [2]. Everything build fine until the 2.38.6 release. From 2.40.x and 2.42.x I'm encountering problems with LLVM (14, 15) and/or C++ functions. Build fails, full log is available here [3]. With GCC there is another problem, but build is ok. On my laptop, WebKitGTK takes about 5 hours to build, and with the latest releases (2.40 and higher) we need a lot of RAM more than 8G. The 6.0 API is available since the 2.40.0 release. [1] https://codeberg.org/olivierd/freebsd-ports-gnome/src/branch/44/Mk/Uses/webkit.mk [2] https://codeberg.org/olivierd/freebsd-ports-gnome/src/branch/44/www/webkit2-gtk3/Makefile [3] https://codeberg.org/olivierd/freebsd-ports-wip/src/branch/master/logs/clang15-webkit2-gtk4-2.40.2.log
(In reply to Olivier Duchateau from comment #4) I will test [1] and [2] very soon. You added flavors for APIs :) It will be nice because I maintain a port that is in need for 4.1 API to get updated. > On my laptop, WebKitGTK takes about 5 hours to build, and with the latest > releases (2.40 and higher) we need a lot of RAM more than 8G. My i7-10750H /16GB laptop takes >6 hours building chromium, 1 poudriere job with all cores on it, tpmfs off and I got used to see swap being hit (hard sometimes). 2 hours on gcc12 with swap used at ~500MB and sometimes 1GB. Impressive numbers.
(In reply to Olivier Duchateau from comment #4) I've just confirmed with openbsd webkit maintainer that they build it fine with clang 13 and 16 but not sure about specific clang patches applied to port. I will start testports with your patches today and share results.
To easily test, I've submitted a patch [1] which contains: - Update www/libwpe to 1.14.1 - Update www/wpebackend-fdo to 1.14.2 - Update www/webkit2-gtk(3,4) to 2.38.6 - Add Mk/Uses/webkit.mk www/webkit2-gtk3 contains FLAVORS for the 4.0 and 4.1 APIs. [1] https://codeberg.org/olivierd/freebsd-ports-gnome/src/branch/patch/0001-www-webkit2-gtk-3-4-update-to-2.38.6.patch
When I tried to build 2.40.x and 2.42.x releases (with clang 14 and 15 ), I got following errors >In file included from /usr/ports/www/webkit2-gtk4/work/webkitgtk-2.40.2/Source/WebKit/WebKit2Prefix.h:75: >In file included from /usr/include/c++/v1/algorithm:667: >In file included from /usr/include/c++/v1/functional:499: >In file included from /usr/include/c++/v1/__functional/bind.h:17: >/usr/include/c++/v1/tuple:1596:5: error: attempt to use a deleted function > _VSTD::__invoke_constexpr( > ^ >/usr/include/c++/v1/__config:826:15: note: expanded from macro '_VSTD' >#define _VSTD std > ^ > /usr/ports/www/webkit2-gtk4/work/webkitgtk-2.40.2/Source/WebKit/Platform/IPC/Decoder.h:132:20: error: call to implicitly-deleted copy constructor of 'std::optional<tuple<expected<pair<ObjectIdentifier<FileSystemHandleIdentifierType>, bool>, FileSystemStorageError>>>' > return t; > ^ Full log is available [1]. [1] https://codeberg.org/olivierd/freebsd-ports-wip/src/branch/master/logs/clang15-webkit2-gtk4-2.40.2.log
(In reply to Olivier Duchateau from comment #8) Could you provide patch for 2.40.2 because patches doesn't apply clean when I switch for 2.28 to this one. Ready to test on 14 and current, I'm curious about results :)
> Mk/Uses/webkit.mk Why? If this is going to be flavourised, all three should be in the same port.
(In reply to Nuno Teixeira from comment #9) (...) Fix typo: - Applied 0001-www-webkit2-gtk-3-4-update-to-2.38.6.patch - Update webkit gtk4 from 2.38.6 -> 2.40.2 - `make patch` fails
https://github.com/shamazmazum/freebsd-ports/tree/master/www Maybe worth to take a look at workaround to build 2.42.4. It implies patch base compiler. ### -# if defined(__FreeBSD__) -# define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR -# endif +//# if defined(__FreeBSD__) +//# define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR +//# endif ###
I decided give a try on -gtk4 port and I found that some patches were taken from openbsd port and didn't been adusted to freebsd. We can see that by greping OPENBSD and see that most of those patches are doing nothing. I adjusted patches when it seems to be logic to FREEBSD and I've got same result as Olivier: (6 errors generated) ### /usr/include/c++/v1/optional:841:35: note: candidate constructor template not viable: requires single argument '__v', but 2 arguments were provided 841 | _LIBCPP_CONSTEXPR_SINCE_CXX20 optional(const optional<_Up>& __v) | ^ ~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/v1/optional:849:44: note: candidate constructor template not viable: requires single argument '__v', but 2 arguments were provided 849 | _LIBCPP_CONSTEXPR_SINCE_CXX20 explicit optional(const optional<_Up>& __v) | ^ ~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/v1/optional:859:35: note: candidate constructor template not viable: requires single argument '__v', but 2 arguments were provided 859 | _LIBCPP_CONSTEXPR_SINCE_CXX20 optional(optional<_Up>&& __v) ### I've googled about _LIBCPP_CONSTEXPR_SINCE_CXX20 and found that dim@ have solved some related problems on gcc, etc. This weekend I will give a try at https://github.com/shamazmazum/freebsd-ports/tree/master/www and see how it goes.
(In reply to Nuno Teixeira from comment #13) (...) work done on 2.42.4
(In reply to Nuno Teixeira from comment #14) Using shamaz port (-gtk3) ### In file included from /wrkdirs/usr/ports/www/webkit2-gtk3/work/.build/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-51.cpp:1: /wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/graphics/gstreamer/MediaSampleGStreamer.cpp:128:12: error: call to implicitly-deleted copy constructor of 'PlatformSample' 128 | return sample; | ^~~~~~ /wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/MediaSample.h:66:7: note: copy constructor of 'PlatformSample' is implicitly deleted because field 'sample' has a deleted copy con structor 66 | } sample; | ^ /wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/MediaSample.h:65:83: note: copy constructor of '(unnamed union at /wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source /WebCore/platform/MediaSample.h:61:5)' is implicitly deleted because variant field 'byteRangeSample' has a non-trivial copy constructor 65 | std::pair<MTPluginByteSourceRef, std::reference_wrapper<const TrackInfo>> byteRangeSample; | ^ 1 error generated. ### Found old issue on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255528#c3 that share same error and a revert was done to fix it: I'm working on patch-revert-11ccaf183fad that fails to get applied on new version.
(In reply to Nuno Teixeira from comment #15) (...) It ends in same error as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275914#c13
Nuno, did you try with gcc? WebKitGTK builds fine with this compiler. When I tested it was with gcc 12, but something is wrong with this compiler (I don't remember why). readelf(1) shows me libwebkitgtk-6.0.so (or libjavascriptcoregtk-6.0.so) was linked with wrong version of gcc (and crashes Epiphany). It also knows problem, there are several cases with same problem. Perhaps a test with higher version fixes this behaviour. As WebKitGTK builds fine with gcc, I also tried to change the C++ standard library (USE_CXXSTD) but this change is not "propagated" when compiler is detected during configure stage. Our ports framework is not to blame! And there is nothing in CMakeFile.txt where we could change this library.
(In reply to Olivier Duchateau from comment #17) > Nuno, did you try with gcc? I will try to avoid it. It must be compiled with clang. Changing to gcc is not a solution unless we dealing with a special case. My plan is to patch base/port clang to see how it goes with: -# if defined(__FreeBSD__) -# define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR -# endif +//# if defined(__FreeBSD__) +//# define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR +//# endif And then try to get help on why this is affecting build. I've contacted author from https://github.com/shamazmazum/freebsd-ports/tree/master/www and he said to me that it was the only solution found to fix it.
(In reply to Nuno Teixeira from comment #18) I've patched lang/llvm16 and used shamaz port (USES+=llvm:16), same build error with/without patch: In file included from /wrkdirs/usr/ports/www/webkit2-gtk3/work/.build/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-51.cpp:1: /wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/graphics/gstreamer/MediaSampleGStreamer.cpp:128:12: error: call to implicitly-deleted copy constructor of 'PlatformSample' return sample; ^~~~~~ /wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/MediaSample.h:66:7: note: copy constructor of 'PlatformSample' is implicitly deleted because field 'sample' has a deleted copy con structor } sample; ^ /wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/MediaSample.h:65:83: note: copy constructor of '(unnamed union at /wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source /WebCore/platform/MediaSample.h:61:5)' is implicitly deleted because variant field 'byteRangeSample' has a non-trivial copy constructor std::pair<MTPluginByteSourceRef, std::reference_wrapper<const TrackInfo>> byteRangeSample; ^ 1 error generated.
(In reply to Nuno Teixeira from comment #19) > I've patched lang/llvm16 ** devel/llvm16 Any clues, any tips for further tests?
I just created review D43762 based from Olivier's 2.38.6 work, which we know builds without much issue. I consolidated all three combinations into one port, as the same exact codebase and build process cannot warrant more plus a Uses/.mk to boot. I'd like to commit 2.38 as a stopgap to allow consumers to adjust/correct their dependencies accordingly. We can keep this bug open to continue working on 2.42.
(In reply to Charlie Li from comment #21) Hello Charlie! I did take a look at review and it seem very promising. I will test it very soon. Thanks!
Testing with (mainly) epiphany, so far 2.38 "hangs" on launch as an effective zombie process, no window appears. truss(1)-ing both epiphany and WebKitWebDriver (what epiphany and other HTML-rendering consumers should spawn) shows something timing out and files not found, thence nothing until interrupted or killed.
(In reply to Charlie Li from comment #23) Turns out there seems to be an indefinite wait condition in JavaScriptCore threading that is blocking further execution: (lldb) bt * thread #1, name = 'epiphany', stop reason = step over * frame #0: 0x000000082652a882 libthr.so.3`cond_wait_common [inlined] cond_wait_user(cvp=0x00003fcdfa8fd980, mp=0x00003fcdfae0c208, abstime=0x0000000000000000, cancel=1) at thr_cond.c:323:24 frame #1: 0x000000082652a7af libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=0x0000000000000000, cancel=1) at thr_cond.c:378:11 frame #2: 0x000000084098ac6d libjavascriptcoregtk-4.1.so.0`WTF::ThreadCondition::wait(WTF::Mutex&) at ThreadingPOSIX.cpp:603:18 frame #3: 0x000000084098ad66 libjavascriptcoregtk-4.1.so.0`WTF::ThreadCondition::timedWait(WTF::Mutex&, WTF::WallTime) at ThreadingPOSIX.cpp:613:9 frame #4: 0x00000008408b2cea libjavascriptcoregtk-4.1.so.0`WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, WTF::TimeWithDynamicClockType const&) at ParkingLot.cpp:595:34 frame #5: 0x000000083f607dc4 libjavascriptcoregtk-4.1.so.0`WTF::ParkingLot::ParkResult WTF::ParkingLot::parkConditionally<bool WTF::Condition::waitUntilUnchecked<WTF::Lock>(WTF::Lock&, WTF::TimeWithDynamicClockType const&)::'lambda'(), bool WTF::Condition::waitUntilUnchecked<WTF::Lock>(WTF::Lock&, WTF::TimeWithDynamicClockType const&)::'lambda0'()>(void const*, WTF::Lock const&, bool WTF::Condition::waitUntilUnchecked<WTF::Lock>(WTF::Lock&, WTF::TimeWithDynamicClockType const&)::'lambda0'() const&, WTF::TimeWithDynamicClockType const&) at ParkingLot.h:82:16 frame #6: 0x000000083f607d00 libjavascriptcoregtk-4.1.so.0`bool WTF::Condition::waitUntilUnchecked<WTF::Lock>(WTF::Lock&, WTF::TimeWithDynamicClockType const&) at Condition.h:192:22 frame #7: 0x000000083f607bc5 libjavascriptcoregtk-4.1.so.0`WTF::Condition::waitUntil(WTF::Lock&, WTF::TimeWithDynamicClockType const&) at Condition.h:77:16 frame #8: 0x0000000840974649 libjavascriptcoregtk-4.1.so.0`bool WTF::Condition::waitUntilUnchecked<WTF::Lock, WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&)::$_0>(WTF::Lock&, WTF::TimeWithDynamicClockType const&, WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&)::$_0 const&) at Condition.h:213:18 frame #9: 0x00000008409745ed libjavascriptcoregtk-4.1.so.0`bool WTF::Condition::waitUntil<WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&)::$_0>(WTF::Lock&, WTF::TimeWithDynamicClockType const&, WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&)::$_0 const&) at Condition.h:91:16 frame #10: 0x0000000840974566 libjavascriptcoregtk-4.1.so.0`WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&) at BinarySemaphore.cpp:41:34 frame #11: 0x0000000840898957 libjavascriptcoregtk-4.1.so.0`WTF::BinarySemaphore::wait() at BinarySemaphore.h:51:9 frame #12: 0x0000000840978c11 libjavascriptcoregtk-4.1.so.0`WTF::WorkQueueBase::platformInitialize(char const*, WTF::WorkQueueBase::Type, WTF::Thread::QOS) at WorkQueueGeneric.cpp:53:15 frame #13: 0x000000084091f4b1 libjavascriptcoregtk-4.1.so.0`WTF::WorkQueueBase::WorkQueueBase(char const*, WTF::WorkQueueBase::Type, WTF::Thread::QOS) at WorkQueue.cpp:55:5 frame #14: 0x00000008408ca439 libjavascriptcoregtk-4.1.so.0`WTF::WorkQueue::WorkQueue(char const*, WTF::Thread::QOS) at WorkQueue.h:104:11 frame #15: 0x000000084091f57b libjavascriptcoregtk-4.1.so.0`WTF::WorkQueue::create(char const*, WTF::Thread::QOS) at WorkQueue.cpp:65:26 frame #16: 0x0000000836ae973d libwebkit2gtk-4.1.so.0`WebKit::DeviceIdHashSaltStorage::DeviceIdHashSaltStorage(WTF::String const&) at DeviceIdHashSaltStorage.cpp:70:15 frame #17: 0x0000000836ae93e9 libwebkit2gtk-4.1.so.0`WebKit::DeviceIdHashSaltStorage::create(WTF::String const&) at DeviceIdHashSaltStorage.cpp:49:50 frame #18: 0x0000000836f65359 libwebkit2gtk-4.1.so.0`WebKit::WebsiteDataStore::WebsiteDataStore(WTF::Ref<WebKit::WebsiteDataStoreConfiguration, WTF::RawPtrTraits<WebKit::WebsiteDataStoreConfiguration>>&&, PAL::SessionID) at WebsiteDataStore.cpp:132:33 frame #19: 0x0000000836f651e3 libwebkit2gtk-4.1.so.0`WebKit::WebsiteDataStore::create(WTF::Ref<WebKit::WebsiteDataStoreConfiguration, WTF::RawPtrTraits<WebKit::WebsiteDataStoreConfiguration>>&&, PAL::SessionID) at WebsiteDataStore.cpp:125:26 frame #20: 0x0000000836dfc8dc libwebkit2gtk-4.1.so.0`webkitWebsiteDataManagerGetDataStore(_WebKitWebsiteDataManager*) at WebKitWebsiteDataManager.cpp:494:34 frame #21: 0x0000000836dfe1d9 libwebkit2gtk-4.1.so.0`webkit_website_data_manager_set_persistent_credential_storage_enabled at WebKitWebsiteDataManager.cpp:887:5 frame #22: 0x000000082170634f libephymain.so`___lldb_unnamed_symbol6069 + 127 frame #23: 0x0000000824574ea0 libgobject-2.0.so.0`g_object_new_internal(class=0x00003fcdfa836400, params=0x0000000820542380, n_params=3) at gobject.c:2296:5 frame #24: 0x00000008245749e2 libgobject-2.0.so.0`g_object_new_valist(object_type=70153904340096, first_property_name="application-id", var_args=0x0000000820542580) at gobject.c:2584:16 frame #25: 0x0000000824573f2c libgobject-2.0.so.0`g_object_new(object_type=70153904340096, first_property_name="application-id") at gobject.c:2057:12 frame #26: 0x00000008216d169d libephymain.so`_ephy_shell_create_instance + 205 frame #27: 0x000000000022708c epiphany`main + 1340 frame #28: 0x00000008279376c6 libc.so.7`__libc_start1(argc=1, argv=0x00000008205426c8, env=0x00000008205426d8, cleanup=<unavailable>, mainX=(epiphany`main)) at libc_start1.c:157:7 frame #29: 0x00000000002262a0 epiphany`_start + 48
*** Bug 277526 has been marked as a duplicate of this bug. ***
*** Bug 279991 has been marked as a duplicate of this bug. ***
Some testing updates since no one has said anything for some time: 2.42 still exhibits similar indefinite wait behaviour as comment 24. With the base system modification to use the newer but unstable libc++ (per LLVM upstream) std::pair ABI, this is the last version to build successfully with clang. Note that I only tested on -CURRENT. 2.44 has some additional fallout on top of the modifications needed for 2.42. Currently trying a build with gcc (14) without any modifications. Given that the newer std::pair ABI will not feature in our base system until upstream LLVM declares it stable, that it will be a while until all supported base systems ship it, and the runtime issues with a clang-based build, I am inclined to special case this port and include USE_GCC if this test is successful.
Got 2.42 built with USE_GCC with only the Source/WebCore/platform/network/DNS.h (adds needed <sys/socket.h> include) and Source/UI/WebProcess/Launcher/glib/ProcessLauncherGLib.cpp patches on -CURRENT. Runtime, on the last upstream www/epiphany that uses the 4.1 API, still exhibits an indefinite wait behaviour. Should probably test with the latest upstream epiphany that uses the 6.0 API however. 2.44 specifically fails whilst building the Layer-Based SVG Engine (LBSE) under both GCC and clang. Downcasts that haven't really changed from the legacy SVG engine are no longer resolving (one example shown): FAILED: Source/WebCore/CMakeFiles/WebCore.dir/rendering/svg/RenderSVGResourceLinearGradient.cpp.o [snip] In file included from /wrkdirs/overlays/overlay/www/webkit2-gtk/work-40/.build/WTF/Headers/wtf/StdLibExtras.h:38, from /wrkdirs/overlays/overlay/www/webkit2-gtk/work-40/.build/WTF/Headers/wtf/FastMalloc.h:26, from /wrkdirs/overlays/overlay/www/webkit2-gtk/work-40/webkitgtk-2.44.2/Source/WebCore/config.h:47, from /wrkdirs/overlays/overlay/www/webkit2-gtk/work-40/webkitgtk-2.44.2/Source/WebCore/rendering/svg/RenderSVGResourceLinearGradient.cpp:22: /wrkdirs/overlays/overlay/www/webkit2-gtk/work-40/.build/WTF/Headers/wtf/TypeCasts.h: In instantiation of 'static bool WTF::TypeCastTraits<ExpectedType, ArgType, isBaseType>::isOfType(ArgType&) [with ExpectedType = const WebCore::SVGLinearGradientElement; ArgType = const WebCore::SVGElement; bool isBaseType = false]': /wrkdirs/overlays/overlay/www/webkit2-gtk/work-40/.build/WTF/Headers/wtf/TypeCasts.h:58:71: required from 'bool WTF::is(const ArgType&) [with ExpectedType = WebCore::SVGLinearGradientElement; ArgType = WebCore::SVGElement]' 58 | return TypeCastTraits<const ExpectedType, const ArgType>::isOfType(source); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ /wrkdirs/overlays/overlay/www/webkit2-gtk/work-40/.build/WTF/Headers/wtf/TypeCasts.h:120:5: required from 'WTF::match_constness_t<Source, Target>& WTF::downcast(Source&) [with Target = WebCore::SVGLinearGradientElement; Source = WebCore::SVGElement; match_constness_t<Source, Target> = WebCore::SVGLinearGradientElement]' 120 | ASSERT_WITH_SECURITY_IMPLICATION(is<Target>(source)); /wrkdirs/overlays/overlay/www/webkit2-gtk/work-40/webkitgtk-2.44.2/Source/WebCore/rendering/svg/RenderSVGResourceLinearGradientInlines.h:36:46: required from here 36 | return downcast<SVGLinearGradientElement>(RenderSVGResourceContainer::element()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /wrkdirs/overlays/overlay/www/webkit2-gtk/work-40/.build/WTF/Headers/wtf/TypeCasts.h:41:28: error: static assertion failed: Missing TypeCastTraits specialization 41 | static_assert(std::is_void_v<ExpectedType>, "Missing TypeCastTraits specialization"); | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~ /wrkdirs/overlays/overlay/www/webkit2-gtk/work-40/.build/WTF/Headers/wtf/TypeCasts.h:41:28: note: 'std::is_void_v<const WebCore::SVGLinearGradientElement>' evaluates to false These apparently resolve on Linux and other platforms. In the meantime there is a private ENABLE_LAYER_BASED_SVG_ENGINE that is enabled for GTK by default, going to try disabling it here.
2.44 available to (at least, build) test at review D45878. USE_GCC unconditionally due to review D35327. Turns out the errors in comment 28 are from disabling ENABLE_UNIFIED_BUILDS. Need to test with a newer www/epiphany as 43 (the last version to use the 4.1 API) in my local tree may harbour some incompatibilities with later webkitgtk, which may explain the crash on startup (and the indefinite wait conditions with 2.42 and earlier).
Aloha, i ported the Nyxt Webbrowser to FreeBSD and an old Webkit Version hits it. Is there anything i can help you with to finish this PR? Also, I saw in the Review, that you updated to 2.44.2. The latest version should be 2.45.5. I am not a C developer, but i can support you with build-tests ( i have a small server cluster) and testing. Please let me know, how we can get this done :) Best, Torsten
(In reply to Torsten Zuehlsdorff from comment #30) No, 2.45 is a development release series for the upcoming 2.46, thus the latest release series remains 2.44. This still follows GNOME's old even-odd release-development versioning split. Build tests are not the biggest issue, but rather runtime has gotten very dodgy since 2.38, if it runs at all. Please keep testing and reporting runtime issues if/when they come up.
> No, 2.45 is a development release series for the upcoming 2.46, thus the latest release series remains 2.44. This still follows GNOME's old even-odd release-development versioning split. I see, thank you for the explanation :) > Build tests are not the biggest issue, but rather runtime has gotten very dodgy since 2.38, if it runs at all. Please keep testing and reporting runtime issues if/when they come up. Actually i have a build issue. When applying the patch and trying to build my created Nyxt Port it fails with: "Unhandled LOAD-FOREIGN-LIBRARY-ERROR in thread #<SB-THREAD:THREAD tid=105072 "main thread" RUNNING {1000AB0003}>: Unable to load any of the alternatives: ("libwebkit2gtk-4.1.so.0" "libwebkit2gtk-4.1.so" "libwebkit2gtk-4.0.so.37" "libwebkit2gtk-4.0.so")" If i revert the patch and build against HEAD it builds fine again. This is very odd, since i can't see any big differences in the build-logs. And the files do exist. So currently i have no clue about this issue.
(In reply to Nuno Teixeira from comment #19) Do not know if it is still relevant, but I suggest you are doing something wrong. Maybe you have patched llvm in base, but use llvm from the ports. You should patch all llvms in your system with that patch and recompile the whole world and packages. I am the author of that repository, currently I use webkit 2.42.5
I also asked if support for DMA-BUF is planned in FreeBSD (needed for WebGL in WebKit since 2.44.0) and was redirected here, but I suggest it's not a relevant discussion.
(In reply to shamaz.mazum from comment #33) As I said: > I've patched lang/llvm16 and used shamaz port (USES+=llvm:16) ... I patched the right llvm as it seems. But it should be more tests around this since it works for you.
(In reply to Nuno Teixeira from comment #35) With all respect, I am 90% sure, you are doing something wrong. /wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/MediaSample.h:65:83: note: copy constructor of '(unnamed union at /wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source /WebCore/platform/MediaSample.h:61:5)' is implicitly deleted because variant field 'byteRangeSample' has a non-trivial copy constructor std::pair<MTPluginByteSourceRef, std::reference_wrapper<const TrackInfo>> byteRangeSample; ^ 1 error generated. This says exactly that the patch wasn't applied. Can you show the output of the following program compiled with that compiler? #include <iostream> #include <utility> #include <type_traits> int main () { bool trivial = std::is_trivially_copy_constructible<std::pair<int, int>>(); std::cout << "std::pair copy constructor is " << (trivial ? "trivial" : "non-trivial") << std::endl; return 0; }
Please, double check that it's the same compiler you have patched. Maybe you have forgotten to bump PORTREVISION and poudriere uses an old package without rebuilding it. I myself never used USES+=llvm:16. Are you sure that this forces llvm from lang/llvm16 and not from the base? Because my llvm in the base is 16.0.6 Can you run top to verify? Sorry if I pry too much, but that patch *must* eliminate that kind of error.
(In reply to shamaz.mazum from comment #37) Ok, I will start testing patch again since you are giving me confidence. My plan will be to patch llvm from ports, bump port revision [1] so we can have better logs that "proves" that patch is correctly applied. Also, from poudriere interactive jails I will execute your program and save results toguether with rest of logs. I will start doing builds tomorrow. Any preference on what llvm version should I start? I'm using llvm 18 default for about 700 pkgs that I use localy. [1] yep, it is possible that I used a local llvm cached pkg... You program will be awesome to check this. Cheers
(In reply to Nuno Teixeira from comment #38) Great news, thanks! I use llvm 16 right now. As an additional (and currently completely optional) test, please let me know if you will be able to actually run any application which uses WebKit. (Unfortunately, that port doesn't build minibrowser). I am not sure if it is possible because of difference in ABI in the C++ standard library provided by the port and the base (I never tested it). If you are familiar with Common Lisp, you can run a demo browser provided with cl-webkit2
(In reply to shamaz.mazum from comment #36) I have patched devel/llvm16. Results from llvm 16 and 18 are the same: % clang++18 check.cc % ./a.out std::pair copy constructor is non-trivial % rm a.out % clang++16 check.cc % ./a.out std::pair copy constructor is non-trivial Patch used: (devel/llvm16/files/patch-libcxx_include_____config) --- libcxx/include/__config.orig 2024-08-23 10:54:26 UTC +++ libcxx/include/__config @@ -162,9 +162,9 @@ # endif // Feature macros for disabling pre ABI v1 features. All of these options // are deprecated. -# if defined(__FreeBSD__) -# define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR -# endif +//# if defined(__FreeBSD__) +//# define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR +//# endif # endif # if defined(_LIBCPP_BUILDING_LIBRARY) || _LIBCPP_ABI_VERSION >= 2
(In reply to Nuno Teixeira from comment #40) I have no idea. Today i've upgraded to FreeBSD 14.1, so this is what I have now with that patch applied to the base: vasily@vonbraun:~/test % c++ --version FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git llvmorg-18.1.5-0-g617a15a9eac9) Target: x86_64-unknown-freebsd14.1 Thread model: posix InstalledDir: /usr/bin vasily@vonbraun:~/test % c++ -o test test.cpp vasily@vonbraun:~/test % ./test std::pair copy constructor is trivial and to the port: vasily@vonbraun:~/test % clang++15 --version clang version 15.0.7 Target: x86_64-portbld-freebsd14.0 Thread model: posix InstalledDir: /usr/local/llvm15/bin vasily@vonbraun:~/test % clang++15 -o test test.cpp vasily@vonbraun:~/test % ./test std::pair copy constructor is trivial I don't know how it's even possible that it works for me and not for you.
(In reply to Nuno Teixeira from comment #40) I hate to ask, but can you apply this patch to the base, as it's recommended in my instruction. I mean, apply this patch in /usr/src, build the world with `make buildworld` and install it to a separate jail. Then try to compile and run that program in that jail. May be a waste of time, but who knows, maybe it will work this way.
(In reply to Nuno Teixeira from comment #40) Wait! LLVM from ports does not install the headers. It uses /usr/include/c++/v1/__utility/pair.h for #include <pair>. Please, patch the base (you can install the world to a jail then). Then it will work. As you can see, my patch cannot be applied only to a port :(
(In reply to shamaz.mazum from comment #42) It seems that patching llvm from ports isn't enough. Patching base compiler is a exccessive measure that will be dificult to test. As I said in this PR when I've found you patched tree, is that this is a proof that your workaround works. Now we need to get expert opinion on this matter on why it is fixed by it. A better solution should be found that not implies patching base or ports compilers.
(In reply to Nuno Teixeira from comment #44) Yes, you are right. This is more like a solution for one person, namely me, as removing those lines from LLVM will lead to a standard library binary incompatible with previously built C++ programs. It will make an upgrade a painful experience. Unfortunately, I know no other option. Just if somebody desperately needs webkit, he will know what to do ;) And like we have not enough promblems, WebKit developers have broken WebGL support in the most recent version (it now requires that DMABUF shit) ;)
Bumping libc++.so to 2 in base will not happen anytime soon. dim@ provided additional context elsewhere about how we adopted LLVM's libc++ early, ie when std::pair was only at version 1. Other operating systems adopted libc++ later when version 2 became available. However, one of our conditions to bumping to version 2 is when LLVM upstream marks the ABI as stable, which has *still* not happened. This is part of why we will most likely need to roll with GCC/libstdc++ for the foreseeable future.
Does it means the end of webkit2-gtk3 and related applications? TY
I don't see any public visible progress, so may i ask: what is ongoing in the background? :D Since we have some pending ports/issues that needs www/webkit2-gtk with 2.44.x: would it be an option to create a parallel port with 2.44.x, build ports with the new version that supports this and fix the rest without blocking anything else? We often do that with the rubygem ports - is this a viable option here too? What do you think?
(In reply to Torsten Zuehlsdorff from comment #48) In short, no. The current versions in the tree barely work runtime-wise to begin with. Even if an update builds fine, that does not mean they actually work as intended, especially for something as complex as a rendering and JavaScript engine. The main test battery (apart from the source's unit tests that I haven't tried yet?), even per upstream, is using www/epiphany. I actually need to update the phab as I have 2.46 built successfully for a few weeks now, but not runtime tested. It will continue to use GCC.
> I actually need to update the phab as I have 2.46 built successfully for a few weeks now, but not runtime tested. It will continue to use GCC. An update would be greatly appreciated! In this case, i can try to build my www/nyxt port against it and runtime test this one :) But I did not get, why we can't create a second port for the new version and switch ports depending on them after a good test. Now we need to test everything depending on it, instead of focusing on single ports and then switching dependencies step by stepö
(In reply to Torsten Zuehlsdorff from comment #50) File conflicts amongst other problems. Only one version per SONAME is meant to be installed in the same environment at a time. You cannot just move certain ports to the new port whilst keeping others on the existing one, especially where dependencies are shared. phab is updated with 2.46.3, but I haven't had a chance to runtime test anything yet.
review D45878 has been updated to 2.46.5
*** Bug 280054 has been marked as a duplicate of this bug. ***
Testing with epiphany 47.2, which uses -6.0, the main issue I've been running into has been WebKitNetworkProcess immediately crashing, preventing any further meaningful use. Until this is figured out, all consumers will not work properly even at a basic level. Currently looking at where ProcessLauncherGLib goes wrong, especially how the local patch merely preprocesses out pidSocketString, which is part of the IPC code gated under OS(LINUX), just to make the build continue.
(In reply to Charlie Li from comment #54) Hi! That's me again. Currently running nyxt with Webkit version 2.46.5. Everything is working fine. Regarding ProcessLauncherGlib, try this patch: https://github.com/shamazmazum/freebsd-ports/blob/master/www/webkit2-gtk3/files/patch-Source_WebKit_UIProcess_Launcher_glib_ProcessLauncherGLib.cpp All other patches I had to apply is here: https://github.com/shamazmazum/freebsd-ports/tree/master/www/webkit2-gtk3/files
(In reply to shamaz.mazum from comment #55) The ProcessLauncherGLib is what I have (as of this writing) in phab, but I don't think is correct for us. Your other patches don't appear to address WebKitNetworkProcess crashing or not launching or being accounted for properly. While it's great that you have nyxt working, the primary testing and qualification battery per upstream is epiphany, and given that this port is intended for GTK, particularly GNOME-related software, we need to verify that epiphany works as intended.
(In reply to Charlie Li from comment #56) You do emphasize Epiphany. Does it mean that you have MiniBrowser from webkitgtk distribution working? I wanted to share how I solved my problem with ProcessLauncherGlib (it may be useful for others), that's all Oh, I forgot one thing. When you get your webkit working on gtk3, you may need this in .login: setenv WEBKIT_DISABLE_DMABUF_RENDERER 1 otherwise UI may freeze from time to time. On gtk4 you don't need this hack.
(In reply to shamaz.mazum from comment #57) epiphany has been on GTK 4 since 44. WEBKIT_DISABLE_DMABUF_RENDERER is irrelevant as nothing gets to render at all after WebKitNetworkProcess crashes on both epiphany and MiniBrowser (except for "WebKit encountered an internal error" displayed on MiniBrowser). Speaking of WebKitNetworkProcess, it turns out something between libsoup{,3} -> glib-networking -> libproxy causes the crash. Updating libproxy (port update to come soon enough) allows loading to advance. I've also found WEBKIT_DISABLE_DMABUF_RENDERER not needed on -4.0 and -4.1. This is all on MiniBrowser; epiphany still needs some work.
(In reply to Charlie Li from comment #58) WebKitWebProcess simply takes a suspiciously long time to initially load before becoming useful in epiphany compared to MiniBrowser, but things appear to work as intended following. After the libproxy update in bug 284088 and refreshing this phab review, we should be good to go.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=94310012886105252763e218ec45dfccf778e55e commit 94310012886105252763e218ec45dfccf778e55e Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2025-01-20 22:01:13 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2025-01-21 03:12:19 +0000 www/webkit2-gtk: update to 2.46.5 Changelog: https://github.com/WebKit/WebKit/blob/webkitgtk-2.46.5/Source/WebKit/gtk/NEWS Now consolidated into one port with flavours since the codebase is the same, just linked with different libraries resulting in different SONAMEs and APIs. SONAMEs/flavours: * GTK3 + libsoup = libwebkit2gtk-4.0 (40) * GTK3 + libsoup3 = libwebkit2gtk-4.1 (41) * GTK4 + libsoup3 = libwebkitgtk-6.0 (60) Despite upstream's recommendation to use clang for better skia optimisation, this port now USE_GCC due to extensive std::pair copy constructor use that is not trivial to continue patching to stay working with our libc++ version 1 ABI. See review D35327 for some details. Reported by: eduardo PR: 275914 Differential Revision: https://reviews.freebsd.org/D45878 MOVED | 2 + audio/gsequencer/Makefile | 2 +- cad/PrusaSlicer/Makefile | 2 +- databases/evolution-data-server/Makefile | 2 +- deskutils/bijiben/Makefile | 2 +- deskutils/bookworm/Makefile | 2 +- deskutils/foliate/Makefile | 2 +- deskutils/gnome-initial-setup/Makefile | 2 +- deskutils/gnotime/Makefile | 2 +- deskutils/meteo/Makefile | 2 +- deskutils/rednotebook/Makefile | 2 +- deskutils/showdown/Makefile | 2 +- devel/devhelp/Makefile | 2 +- devel/geany-plugin-markdown/Makefile | 2 +- devel/glade/Makefile | 2 +- devel/gnome-builder/Makefile | 2 +- devel/juce/Makefile | 4 +- devel/juce706/Makefile | 4 +- editors/emacs-devel/Makefile | 2 +- editors/emacs/Makefile | 2 +- editors/marker/Makefile | 2 +- editors/quilter/Makefile | 2 +- editors/setzer/Makefile | 2 +- finance/gnucash/Makefile | 2 +- graphics/atril/Makefile | 2 +- graphics/birdfont/Makefile | 2 +- graphics/gthumb/Makefile | 2 +- graphics/pdfpc/Makefile | 2 +- java/eclipse/Makefile | 2 +- mail/astroid/Makefile | 2 +- mail/balsa/Makefile | 2 +- mail/claws-mail-fancy/Makefile | 2 +- mail/evolution-ews/Makefile | 2 +- mail/evolution/Makefile | 2 +- mail/geary/Makefile | 2 +- math/qalculate-gtk/Makefile | 2 +- misc/xiphos/Makefile | 2 +- net/gnome-online-accounts/Makefile | 2 +- net/liferea/Makefile | 2 +- net/remmina/Makefile | 2 +- print/xreader/Makefile | 2 +- textproc/libgepub/Makefile | 2 +- www/Makefile | 3 +- www/badwolf/Makefile | 2 +- www/deforaos-surfer/Makefile | 2 +- www/eolie/Makefile | 2 +- www/epiphany/Makefile | 4 +- www/luakit-devel/Makefile | 2 +- www/luakit/Makefile | 2 +- www/midori/Makefile | 2 +- www/py-pywebview-gtk/Makefile | 2 +- www/py-pywry/Makefile | 2 +- www/surf/Makefile | 2 +- www/vimb/Makefile | 2 +- www/webkit2-gtk/Makefile (new) | 141 + www/webkit2-gtk/distinfo (new) | 5 + ...ThirdParty_ANGLE_src_common_SimpleMutex.h (new) | 12 + ...ce_ThirdParty_ANGLE_src_common_platform.h (new) | 23 + ...ch-Source_WTF_wtf_glib_FileSystemGlib.cpp (new) | 11 + .../patch-Source_WebCore_platform_network_DNS.h | 4 +- ...ess_Launcher_glib_ProcessLauncherGLib.cpp (new) | 24 + ...Kit_UIProcess_glib_WebProcessPoolGLib.cpp (new) | 11 + ...ource_bmalloc_bmalloc_EligibilityResult.h (new) | 20 + ...malloc_bmalloc_EligibilityResultInlines.h (new) | 11 + ...rce_bmalloc_bmalloc_IsoAllocatorInlines.h (new) | 11 + www/{webkit2-gtk3 => webkit2-gtk}/pkg-descr | 0 www/webkit2-gtk/pkg-plist (new) | 4142 ++++++++++++++++++++ www/webkit2-gtk/pkg-plist_60 (new) | 1677 ++++++++ www/webkit2-gtk3/Makefile (gone) | 111 - www/webkit2-gtk3/distinfo (gone) | 7 - .../patch-Source-cmake-OptionsCommon.cmake (gone) | 11 - ...avaScriptCore_assembler_ARM64Assembler.h (gone) | 11 - ...avaScriptCore_assembler_ARMv7Assembler.h (gone) | 11 - ...tCore_assembler_AbstractMacroAssembler.h (gone) | 11 - ...vaScriptCore_jit_ExecutableAllocator.cpp (gone) | 11 - .../patch-Source_JavaScriptCore_jsc.cpp (gone) | 12 - ...-Source_JavaScriptCore_llint_LLIntData.h (gone) | 56 - ...ource_JavaScriptCore_offlineasm_arm64.rb (gone) | 11 - ...urce_JavaScriptCore_offlineasm_config.rb (gone) | 16 - ...urce_JavaScriptCore_offlineasm_parser.rb (gone) | 28 - ...h-Source_JavaScriptCore_runtime_JSCast.h (gone) | 20 - ...aScriptCore_runtime_NativeExecutable.cpp (gone) | 10 - .../patch-Source_WTF_wtf_PlatformCPU.h (gone) | 18 - .../files/patch-Source_WTF_wtf_RAMSize.cpp (gone) | 34 - ...F_wtf_unix_MemoryPressureHandlerUnix.cpp (gone) | 11 - ...Source_WebCore_platform_PlatformScreen.h (gone) | 15 - ...phics_cpu_arm_filters_FELightingNEON.cpp (gone) | 20 - ...ch-Source_WebCore_platform_network_DNS.h (gone) | 10 - ...urce_WebCore_platform_text_TextCodec.cpp (gone) | 11 - ...patch-Source_WebDriver_PlatformGTK.cmake (gone) | 16 - ...update-LegacyInspectorBackendCommands.rb (gone) | 11 - ...tch-Source_WebKit_webkitglib-symbols.map (gone) | 12 - ...patch-Source_bmalloc_bmalloc_BPlatform.h (gone) | 10 - .../patch-Source_cmake_WebKitCommon.cmake (gone) | 17 - .../files/patch-revert-11ccaf183fad (gone) | 211 - www/webkit2-gtk3/pkg-plist (gone) | 287 -- www/webkit2-gtk4/Makefile (gone) | 117 - www/webkit2-gtk4/distinfo (gone) | 7 - ...raphics_gstreamer_MediaSampleGStreamer.h (gone) | 10 - ...avaScriptCore_assembler_ARM64Assembler.h (gone) | 12 - ...avaScriptCore_assembler_ARMv7Assembler.h (gone) | 12 - ...Core_assembler_MacroAssemblerX86Common.h (gone) | 19 - ...e_JavaScriptCore_javascriptcoregtk.pc.in (gone) | 10 - .../patch-Source_JavaScriptCore_jsc.cpp (gone) | 11 - ...ource_JavaScriptCore_offlineasm_arm64.rb (gone) | 11 - ..._JavaScriptCore_runtime_MachineContext.h (gone) | 118 - ...ource_JavaScriptCore_runtime_Options.cpp (gone) | 25 - ...patch-Source_WTF_wtf_CompletionHandler.h (gone) | 10 - .../files/patch-Source_WTF_wtf_Function.h (gone) | 19 - .../files/patch-Source_WTF_wtf_InlineASM.h (gone) | 12 - .../files/patch-Source_WTF_wtf_PageBlock.h (gone) | 12 - .../files/patch-Source_WTF_wtf_Platform.h (gone) | 13 - .../patch-Source_WTF_wtf_PlatformEnable.h (gone) | 14 - .../patch-Source_WTF_wtf_PlatformHave.h (gone) | 18 - .../files/patch-Source_WTF_wtf_RAMSize.cpp (gone) | 20 - .../files/patch-Source_WTF_wtf_RawHex.h (gone) | 21 - ...Source_WebCore_PAL_pal_PlatformGTK.cmake (gone) | 18 - ...to_algorithms_CryptoAlgorithmAES_GCM.cpp (gone) | 16 - ...ch-Source_WebCore_page_NavigatorBase.cpp (gone) | 21 - ...ch-Source_WebCore_platform_MediaSample.h (gone) | 11 - ...atform_graphics_FontSelectionAlgorithm.h (gone) | 30 - ...phics_gstreamer_MediaSampleGStreamer.cpp (gone) | 15 - ...raphics_gstreamer_MediaSampleGStreamer.h (gone) | 10 - ..._mediasource_MockSourceBufferPrivate.cpp (gone) | 23 - ...e_WebCore_rendering_RenderLayerBacking.h (gone) | 16 - ...patch-Source_WebDriver_PlatformGTK.cmake (gone) | 17 - ...tch-Source_WebKit_Platform_IPC_Decoder.h (gone) | 10 - ...ebKit_gtk_webkit2gtk-web-extension_pc.in (gone) | 10 - ...patch-Source_WebKit_gtk_webkit2gtk_pc.in (gone) | 10 - ...urce_bmalloc_bmalloc_AvailableMemory.cpp (gone) | 90 - ...Source_bmalloc_bmalloc_AvailableMemory.h (gone) | 21 - ...patch-Source_bmalloc_bmalloc_BPlatform.h (gone) | 14 - .../patch-Source_cmake_OptionsCommon.cmake (gone) | 16 - ...h-Source_cmake_WebKitCompilerFlags.cmake (gone) | 16 - www/webkit2-gtk4/pkg-descr (gone) | 10 - www/webkit2-gtk4/pkg-plist (gone) | 4065 ------------------- x11-fm/sushi/Makefile | 2 +- x11-toolkits/swt/Makefile | 2 +- x11-toolkits/wxgtk30/Makefile | 2 +- x11-toolkits/wxgtk32/Makefile | 2 +- x11/ulauncher/Makefile | 2 +- x11/yad/Makefile | 4 +- x11/yelp/Makefile | 2 +- 143 files changed, 6156 insertions(+), 6006 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=bc2e3ed90ba084d29a08ce4c87329e05b61bd317 commit bc2e3ed90ba084d29a08ce4c87329e05b61bd317 Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2025-01-21 02:42:46 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2025-01-21 03:12:20 +0000 www/webkit2-gtk: bump consumer PORTREVISIONs after port consolidation With hat: gnome PR: 275914 audio/gsequencer/Makefile | 1 + cad/PrusaSlicer/Makefile | 2 +- databases/evolution-data-server/Makefile | 2 +- deskutils/bijiben/Makefile | 2 +- deskutils/bookworm/Makefile | 2 +- deskutils/foliate/Makefile | 2 +- deskutils/gnome-initial-setup/Makefile | 2 +- deskutils/gnotime/Makefile | 2 +- deskutils/meteo/Makefile | 1 + deskutils/rednotebook/Makefile | 2 +- deskutils/showdown/Makefile | 2 +- devel/devhelp/Makefile | 2 +- devel/geany-plugin-markdown/Makefile | 1 + devel/glade/Makefile | 2 +- devel/gnome-builder/Makefile | 2 +- devel/juce/Makefile | 2 +- devel/juce706/Makefile | 2 +- editors/marker/Makefile | 2 +- editors/quilter/Makefile | 1 + editors/setzer/Makefile | 2 +- finance/gnucash/Makefile | 1 + graphics/atril/Makefile | 1 + graphics/birdfont/Makefile | 2 +- graphics/gthumb/Makefile | 2 +- graphics/pdfpc/Makefile | 2 +- java/eclipse/Makefile | 2 +- mail/astroid/Makefile | 2 +- mail/balsa/Makefile | 2 +- mail/evolution-ews/Makefile | 2 +- mail/evolution/Makefile | 2 +- mail/geary/Makefile | 2 +- math/qalculate-gtk/Makefile | 1 + misc/xiphos/Makefile | 2 +- net/gnome-online-accounts/Makefile | 2 +- net/liferea/Makefile | 2 +- net/remmina/Makefile | 1 + textproc/libgepub/Makefile | 2 +- www/badwolf/Makefile | 2 +- www/deforaos-surfer/Makefile | 2 +- www/eolie/Makefile | 2 +- www/epiphany/Makefile | 2 +- www/luakit-devel/Makefile | 2 +- www/luakit/Makefile | 2 +- www/midori/Makefile | 2 +- www/py-pywebview-gtk/Makefile | 2 +- www/py-pywry/Makefile | 2 +- www/surf/Makefile | 2 +- www/vimb/Makefile | 2 +- x11-fm/sushi/Makefile | 2 +- x11-toolkits/wxgtk30/Makefile | 2 +- x11-toolkits/wxgtk32/Makefile | 1 + x11/ulauncher/Makefile | 2 +- x11/yelp/Makefile | 2 +- 53 files changed, 53 insertions(+), 44 deletions(-)
Finally committed. Took quite a bit but this software is quite particular about many things.
New port depends on WPE: libwpe-1.0.so:www/libwpe \ libWPEBackend-fdo-1.0.so:www/wpebackend-fdo However WPE renderer was removed in 2.44.0: https://www.webkitgtk.org/2024/03/16/webkitgtk2.44.0-released.html
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3c6dc755c4b773724104e19101926efa0512fda9 commit 3c6dc755c4b773724104e19101926efa0512fda9 Author: Charlie Li <vishwin@FreeBSD.org> AuthorDate: 2025-01-21 13:46:52 +0000 Commit: Charlie Li <vishwin@FreeBSD.org> CommitDate: 2025-01-21 13:46:52 +0000 www/webkit2-gtk: remove no longer needed WPE dependencies since 2.44 Reported by: shamaz.mazum[at]gmail[dot]com PR: 275914 www/webkit2-gtk/Makefile | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)