PF4Public / gentoo-overlay

Personal Gentoo overlay
80 stars 20 forks source link

dev-util/electron-28: patches needed for icu-74 and libxml2-2.12.5 #302

Closed joecool1029 closed 9 months ago

joecool1029 commented 9 months ago

A dupe of #280, but I've needed this patch from that report for over a month: https://raw.githubusercontent.com/gentoo/gentoo/830d6ed5d3210ba88a668dabd2b0d0e446602ba2/dev-qt/qtwebengine/files/qtwebengine-6.5.3-icu74.patch

I also need this patch (the top 2 files) for building with libxml2-2.12.5: https://chromium-review.googlesource.com/c/chromium/src/+/4985186

EDIT: fixed URL typo on second link

PF4Public commented 9 months ago

Just checked, both my build chroots have libxml2-2.12.5, perhaps I've built electron-28 before updating libxml2, I'll try rebuilding electron with latest libxml2 and icu a bit later and update ebuild accordingly.

baconsalad commented 9 months ago

patches work to get v26 to compile for me as well.

PF4Public commented 9 months ago

patches work to get v26 to compile for me as well.

Why are you using electron-26 when even vscode switched to 27?

baconsalad commented 9 months ago

There was a reason I long since forgot. Propbably upgrade to v28 at some point.

PF4Public commented 9 months ago

I'm asking because I plan (actually for a long time already) to prune all electrons<27 now that vscode switched to 27.

baconsalad commented 9 months ago

Just upgraded to v28, works fine.

nethershaw commented 9 months ago

So. Is this the reason all of the electron ebuilds past 25 bail with unresolved symbols?

nethershaw commented 9 months ago

Yeah. This is why the OP is was still using an old version of Electron.

For what it's worth: in case anyone else is struggling with the link to the second set of patches returning 404 because they're tired of burning hours of compilation time and want it to stop, that's because it (somehow...?) contains an extra "i" in "chromium" as though someone had typed the URL out by hand.

This is the real URL. https://chromium-review.googlesource.com/c/chromium/src/+/4985186

Please mask the packages you haven't fully qualified as unstable.

PF4Public commented 9 months ago

So. Is this the reason all of the electron ebuilds past 25 bail with unresolved symbols? Yeah.

@nethershaw Well, not entirely. Initially I wanted to write how I feel unfairly judged in your interpretation, being guilty for someone being "tired of burning hours of compilation time". But if you didn't notice that I was recently very busy elsewhere and only recently found some time to catch up with all the ebuilds in my overlay, it would not matter much to you.

Now that I'm blaimed for doing volunteer work (or rather not doing it for 2 months?) at my own expense I'm thinking whether I did the right decision to spend my recent time on advancing the overlay instead of doing just anything else… Feel discouraged to continue to be honest.

joecool1029 commented 9 months ago

Yeah. This is why the OP ~is~ was still using an old version of Electron.

@nethershaw I was not using an old electron version. I build the current releases, when they fail I manually patch and continue the build from where it failed. (resume with ebuild /path/to/ebuild compile install qmerge).

For what it's worth: in case anyone else is struggling with the link to the second set of patches returning 404 because they're tired of burning hours of compilation time and want it to stop, that's because it (somehow...?) contains an extra "i" in "chromium" as though someone had typed the URL out by hand.

I probably hit a key on my keyboard by accident while submitting, I think most people would have figured it out. Either way it's updated now. It would have been helpful to just mention the URL was broken.

Please mask the packages you haven't fully qualified as unstable.

None of us have the CPU power to run CI on every single build configuration with a package as large as electron. I myself run the builds overnight and when they fail, I patch the errors in the morning and if I'm not that busy or it looks like it's been a thing for some time I file bugs like this. -system-icu users and users on stable arches wouldn't have hit either of these 2 build failures. AITA for not pointing to the patches sooner knowing it was broken or are you the one for not opening an issue to report the failure?

There's a reason this isn't in ::gentoo and a reason for overlays, if you use an overlay it's usually not going to match ::gentoo's QA standards since we do not have the time/resources, we can try but it's all best-effort. Complaining without contributing really demotivates maintainers from providing volunteer services, it's unwelcome.

JohnFlowerful commented 9 months ago

For those using clang, you'll also need

--- cc/layers/mirror_layer_impl.h.old   2024-02-11 11:42:00.713435132 +1300
+++ cc/layers/mirror_layer_impl.h   2024-02-11 11:42:07.582482770 +1300
@@ -56,7 +56,8 @@
  private:
   const char* LayerTypeAsString() const override;
   viz::CompositorRenderPassId mirrored_layer_render_pass_id() const {
-    return viz::CompositorRenderPassId{mirrored_layer_id()};
+    return viz::CompositorRenderPassId{
+        static_cast<uint64_t>(mirrored_layer_id())};
   }

   int mirrored_layer_id_ = 0;

I'll update if there's more.

joecool1029 commented 9 months ago

For those using clang, you'll also need

I'm building with clang-17.0.6 and haven't hit a failure. Is this issue limited to clang-18?

Here's upstream review: https://chromium-review.googlesource.com/c/chromium/src/+/5150303

JohnFlowerful commented 9 months ago

For those using clang, you'll also need

I'm building with clang-17.0.6 and haven't hit a failure. Is this issue limited to clang-18?

Yeah, for >=clang-18. I'm using the old clang18-narrowing.patch from this repo as well as the 3 you mentioned.

nethershaw commented 9 months ago

You can add a tilde to your keywords while you're working on an ebuild; you can remove it when you're done. I can't contribute that for you -- you alone know what you are working on. Don't moralize at me.

PF4Public commented 9 months ago

@JohnFlowerful Have you had any other issues? My build had finished and no more issues it seems.

JohnFlowerful commented 9 months ago

clang-18 ran into https://github.com/llvm/llvm-project/issues/80210 when building pdfium. I switched back to clang-17 with the mentioned patches and it went fine.

I'll try the fixed ebuild today at some stage.

JohnFlowerful commented 9 months ago

Had a fiddle with the above issue. Turns out Gentoo's >=clang-18 packages have the debug useflag enabled. Disabling that got me passed it.