[Bug 261410] www/firefox: Update to 96.0.2 (unfixed security vulnerabilities)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261410

Evgeniy Khramtsov <evgeniy@khramtsov.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gecko@FreeBSD.org
 Attachment #231401|                            |maintainer-approval?(gecko@
              Flags|                            |FreeBSD.org)

--- Comment #9 from Evgeniy Khramtsov <evgeniy@khramtsov.org> ---
Created attachment 231401
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=231401&action=edit
v1.0 (zstd, git)

Updated to 96.0.3, regenerated json+moz.build for aarch64 using
qemu-user-static 13.0/aarch64 chroot, adjusted BUILD_DEPENDS
versions according to rg 'pkg_check_modules'.

QA checklist:
12.2/{i386,amd64}, 13.0/amd64: build tested.
12.2/i386, 13.0/amd64: runtime tested.

13.0/i386 isn't Tier 1 so isn't QA'ed in order to not block security update for
Tier 1.

aarch64 build should likely pass. If it doesn't, consider reverting:
--- x64_False_arm64_freebsd.json
+++ arm64_False_arm64_freebsd.json
@@ -1,13 +1,13 @@
 {
     "gn_gen_args": {
-        "host_cpu": "x64",
+        "host_cpu": "arm64",
         "is_debug": false,
         "target_cpu": "arm64",
         "target_os": "freebsd"
     },
     "mozbuild_args": {
         "CPU_ARCH": "aarch64",
-        "HOST_CPU_ARCH": "x86_64",
+        "HOST_CPU_ARCH": "aarch64",
         "MOZ_DEBUG": null,
         "OS_TARGET": "FreeBSD"
     },

and/or renaming arm64_False_arm64_freebsd.json to x64_False_arm64_freebsd.json.
I followed the rules for generating and target CPU literally from:
https://github.com/mozilla/gecko-dev/blob/release/dom/media/webrtc/third_party_build/gn-configs/README.md
arm64 -> x64 adjustment may be needed if the documentation is incorrect.

ppc64 can also follow later after aarch64 is OK and we get to reproduce
the regen environment/how-to. I already written down some steps
non-sequentielly.

Since v0.8 was proven to be stable for >day by cmt, and this is a point
release with minor moz.build+json readjustment (guard sse2 and avx2 for
PCs, enable neon on aarch64), I believe that regression from v0.8 is
unlikely, which received the following QA:

12.2/{i386,amd64}, 13.0/{amd64}, -CURRENT: build/runtime tested (me).
PipeWire screencapture: tested (jbeich).
v0.8 + 96.0.3: tested for a day (cmt).

--

It seems that I borked my /dev or whatever again, **95.0.2 in the
official repos** and both 96.0.3 can't move tabs with MOZ_ENABLE_WAYLAND
under x11-wm/cage with /dev, XDG_RUNTIME_DIR, WAYLAND_DISPLAY passed
from -CURRENT host. I believe that my issue is not related to 96.0.3
update, but any final testing would be appreciated. I can't test 96
on host because it is far away from vanilla FreeBSD and testing on it
would require rebasing local no-X11 patches on top of 96 which I don't want.

I now disappear for some time to rest.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.