Update to Chromium 130.0.6723.69

[Ahrotahn]

This PR updates to Chromium 130.0.6723.69 There were no notable changes needed on our end.

Google's tarball builders are still working through a pile of failed builds, so it will be a while before that's available.

Change log Blog post

[clickot]

I tried around to checkout the code (by adapting https://gitlab.archlinux.org/archlinux/packaging/packages/chromium/-/blob/main/fetch-chromium-release) but it seems there are files missing in the result. Don't understand why this is so complicated... ;-) I give up and have to wait for the tarball.

[Ahrotahn]

If you still want to attempt a checkout we have a clone script in the utils directory that creates a tarball-compatible source directory using shallow clones. The help option should give details on the flags that can be used.

[networkException]

nixpkgs also doesn't have git checkout for builds yet so Arch it was instead :)

[Cubik65536]

I got a 404 when trying to retrieve chromium source for .6723.69, is it normal (even though we already released the UGC .6723.69)?

[tsuliwaensis]

I'm also getting a 404 when trying to retrieve the source

[networkException]

Yes this is sadly expected as Google still hasn't published a release tarball. I guess that shows that distributions shouldn't rely on them going forward but it'll take time until its supported everywhere

As for ungoogled I think its better to just publish patches based on git instead of blocking downstreams with git fetch support on our release waiting for a tarball

[teeminus]

Windows is using the clone script for quite some time now and it work's great. We also support the tarball as a fallback option.

---

Since the first chrome 130 release, the X86 build for windows failes due to a linking error:

[20059/49529] LINK gen-regexp-special-case.exe gen-regexp-special-case.exe.pdb
FAILED: gen-regexp-special-case.exe gen-regexp-special-case.exe.pdb
..\..\third_party\llvm-build\Release+Asserts\bin\lld-link.exe "/OUT:./gen-regexp-special-case.exe" /nologo -libpath:..\..\third_party\llvm-build\Release+Asserts\lib\clang\20\lib\windows "-libpath:../../../../../Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.39.33519/ATLMFC/lib/x86" "-libpath:../../../../../Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.39.33519/lib/x86" "-libpath:../../../../../Program Files (x86)/Windows Kits/10/lib/10.0.22621.0/ucrt/x86" "-libpath:../../../../../Program Files (x86)/Windows Kits/10/lib/10.0.22621.0/um/x86" /MACHINE:X86  "/PDB:./gen-regexp-special-case.exe.pdb" "@./gen-regexp-special-case.exe.rsp"
lld-link: error: undefined symbol: _tanhf
>>> referenced by obj\third_party\icu\icuuc_private\gen-regexp-special-case.exe.lto.lstmbe.obj:(void __cdecl icu_74::compute(int, class icu_74::ReadArray2D const &, class icu_74::ReadArray2D const &, class icu_74::ReadArray1D const &, class icu_74::ReadArray1D const &, class icu_74::Array1D &, class icu_74::Array1D &, class icu_74::Array1D &))
>>> referenced by obj\third_party\icu\icuuc_private\gen-regexp-special-case.exe.lto.lstmbe.obj:(void __cdecl icu_74::compute(int, class icu_74::ReadArray2D const &, class icu_74::ReadArray2D const &, class icu_74::ReadArray1D const &, class icu_74::ReadArray1D const &, class icu_74::Array1D &, class icu_74::Array1D &, class icu_74::Array1D &))

This does not happen on the X64 build and I am not sure what causes the issue or how to fix it. It might be because I updated to clang 19.1.1 (we used 18.1.8 for chrome 129) but it could also be cause by some google changes.

[Ahrotahn]

The tarball builders are an afterthought for Google, and they once had plans to remove them which was the impetus for creating that cloning script. You can take a look at the backlog on their scheduler page. They are currently three days behind so with any luck that should mean the tarball for .69 will be available over the next day. The problem is that delay will continue to compound until someone at Google cares enough to resolve the build failures and clear out the re-queued entries. At this rate if they have another release on Tuesday then the tarball might not be available until the next week...

---

@teeminus You're correct that it's an LLVM issue. It was introduced in #98949 and there's a fix in #101268, so you would need to either use a pre-19.1 version or a custom build that includes the fix.

[clickot]

@Ahrotahn thanks for pointing me to the utils/clone.py script! Runs now with my portable linux build :) What took me some time: the clone does not contain a file that is in the pruning.list(third_party/node/node_modules/node_modules.tar.gz) . Theprune-binaries.py is rather silent what files it misses when not in debug mode, so it was not obvious for me why the build failed. @networkException the archlinux build as it is now will probably fail because of the same reason. I'll make a pull request that the missing files are logged together with the error message, that is more informative.

[networkException]

Ah right, I changed source fetching to always use a tarball so that sources can be stripped. I guess the AUR release should work at least.

[tsuliwaensis]

@Ahrotahn thanks for pointing me to the utils/clone.py script! Runs now with my portable linux build :) What took me some time: the clone does not contain a file that is in the pruning.list(third_party/node/node_modules/node_modules.tar.gz) . Theprune-binaries.py is rather silent what files it misses when not in debug mode, so it was not obvious for me why the build failed. @networkException the archlinux build as it is now will probably fail because of the same reason. I'll make a pull request that the missing files are logged together with the error message, that is more informative.

What is the fix for the missing file in the clone script?

[Ahrotahn]

@clickot @tsuliwaensis That file exists for me when I do a fresh clone. Is it possible there's something in your build setup that is removing it before the pruning script is run? Maybe gsync is failing, do you get output from the script that gsync gets run?

[clickot]

@tsuliwaensis i "hacked" it by adding a sed command to my build that removes the line from the list of files to prune: sed -i '/third_party\/node\/node_modules\/node_modules.tar.gz/d' <ungoogled-chromium-dir>/pruning.list

[tsuliwaensis]

@clickot @tsuliwaensis That file exists for me when I do a fresh clone. Is it possible there's something in your build setup that is removing it before the pruning script is run? Maybe gsync is failing, do you get output from the script that gsync gets run?

I get this error when I run the clone script

File "/ungoogled-chromium-macos/ungoogled-chromium/utils/chromium/uc_staging/depot_tools/external_bin/gsutil/gsutil_5.28/gsutil/third_party/apitools/apitools/base/protorpclite/messages.py", line 549, in <module>
    class Variant(Enum):
    ...<34 lines>...
        SINT64 = 18

apitools.base.protorpclite.messages.EnumDefinitionError: May only use integers in Enum definitions.

subprocess.CalledProcessError: Command '['chromium/uc_staging/depot_tools/gclient', 'sync', '-f', '-D', '-R', '--no-history', '--nohooks', '--sysroot=None']' returned non-zero exit status 1.

[clickot]

@tsuliwaensis the clone script runs fine for me; later after cloning the build failed because of the missing file to prune. So i don't know what the error causes that you are facing

@Ahrotahn gsync runs without errors in my build as far as i can see. btw: I'm wondering if a missing file to prune is really an error that should cause the build to fail. what do you think?

[Ahrotahn]

@tsuliwaensis See if appending this to the end of utils/depot_tools.patch solves that issue (the whitespace is important):

@@ -131,6 +131,20 @@
             with open(gsutil_flag, 'w') as f:
                 f.write('This flag file is dropped by gsutil.py')

+    subprocess.run(['git', 'apply'], input="""\
+--- a/UC_STAGING/depot_tools/external_bin/gsutil/gsutil_%s/gsutil/third_party/apitools/apitools/base/protorpclite/messages.py
++++ b/UC_STAGING/depot_tools/external_bin/gsutil/gsutil_%s/gsutil/third_party/apitools/apitools/base/protorpclite/messages.py
+@@ -143,7 +143,7 @@ def __str__(self):
+ # Attributes that are reserved by a class definition that
+ # may not be used by either Enum or Message class definitions.
+ _RESERVED_ATTRIBUTE_NAMES = frozenset(
+-    ['__module__', '__doc__', '__qualname__'])
++    ['__module__', '__doc__', '__qualname__', '__static_attributes__'])
+ """ % (VERSION, VERSION) + """
+ _POST_INIT_FIELD_ATTRIBUTE_NAMES = frozenset(
+     ['name',
+""", check=True, universal_newlines=True)
+
     return gsutil_bin

Python 3.13 causes an issue with apitools due to the addition of __static_attributes__, but that is complicated by the fact that gsync downloads it on the fly. So we have to patch gsync to patch that afterwards.

@clickot Does the file exist if you run the clone script on it's own?

[tsuliwaensis]

@Ahrotahn I appended your code block to utils/depot_tools.patch, but it still ended with the same error.

[Ahrotahn]

@tsuliwaensis Check the patch again to see if that change is still there. If you're using it as part of a build script rather than running it manually then it might be getting overwritten in the process. I've just pushed the change to my repo, so if that's what is happening then you could replace the ungoogled-chromium repo with mine temporarily to make that easier.

It's also possible that there is some other section further along that needs to be updated as well, so if you get a similar error for a different file then post that output and I'll take a look.

[tsuliwaensis]

@tsuliwaensis Check the patch again to see if that change is still there. If you're using it as part of a build script rather than running it manually then it might be getting overwritten in the process. I've just pushed the change to my repo, so if that's what is happening then you could replace the ungoogled-chromium repo with mine temporarily to make that easier.

It's also possible that there is some other section further along that needs to be updated as well, so if you get a similar error for a different file then post that output and I'll take a look.

I used the copy from your repo and there's now a different error message. So, progress?

apitools.base.protorpclite.messages.MessageDefinitionError: May only use fields in message definitions.  Found: __firstlineno__ = 35

[Ahrotahn]

Ok, I just added __firstlineno__ to the patch as well. Hopefully those are the only ones needed.

[clickot]

@Ahrotahn i eventually understood what happend to my build concerning the missing node_modules.tar.gz to prune: The fetch-chromium-release script from archlinux chromium packaging that i tried to use executes chromium's third_party/node/update_npm_deps script which updates local node_modules and the file is gone afterwards. So this conflicts with the pruning list executed by prune_binaries.py. The ungoogled-chromium/utils/clone.py doesn't do this. Since i played around with both, i was misleaded. @networkException so it's still true that if you want to use the original fetch-chromium-release for the archlinux build, you will probably have to patch the pruning list (or the script)

[tsuliwaensis]

Ok, I just added __firstlineno__ to the patch as well. Hopefully those are the only ones needed.

I am able to successfully run the clone script. Thank you so much!!

So now do I copy the Chromium folder to /build/src/?

[clickot]

@tsuliwaensis yes you have to copy the content of the checkout folder to build/src :)

[tsuliwaensis]

Thanks everyone for the help!