[create-pull-request] automated change

cobalt/site/docs/gen/cobalt/doc/voice_search.md

@@ -26,15 +26,15 @@ on the SbMicrophone API as detailed above.
 
 In `starboard/linux/shared/soft_mic_platform_service.cc` there is an example
 stub implementation of the SoftMicPlatformService. Platforms can optionally
-implement this [CobaltPlatformService](https://cobalt.dev/gen/cobalt/doc/\
-platform_services.html) to specify if they support the `soft mic` and/or `hard mic`
-for voice search. The `soft mic` refers to the software activation of the microphone
-for voice search through the UI microphone button on the Youtube Web Application
-search page. The `hard mic` refers to hardware button activation of the microphone
-for voice search. Platforms can also specify the optional `micGesture`. This
-specifies the type of UI prompt the YouTube Web Application should display to guide
-the user to start voice search. The options include an empty or `null` value for no
-prompt, `"TAP"` for tap the `soft mic` and/or `hard mic` to start voice search, or
+implement this [CobaltPlatformService](platform_services.md) to specify if they
+support the `soft mic` and/or `hard mic` for voice search. The `soft mic` refers
+to the software activation of the microphone for voice search through the UI
+microphone button on the Youtube Web Application search page. The `hard mic`
+refers to hardware button activation of the microphone for voice search.
+Platforms can also specify the optional `micGesture`. This specifies the type of
+UI prompt the YouTube Web Application should display to guide the user to start
+voice search. The options include an empty or `null` value for no prompt,
+`"TAP"` for tap the `soft mic` and/or `hard mic` to start voice search, or
 `"HOLD"` for hold the `soft mic` and/or the `hard mic` to start voice search.
 
 The Web Application messages to the platform will be singular strings, encoded with

cobalt/site/docs/gen/starboard/build/doc/migrating_gyp_to_gn.md

@@ -266,8 +266,8 @@ This [document](./gn_migrate_stub_to_platform.md) outlines a step by step
 process for converting the stub platform's GN files to GN files that will be
 able to be built for your platform.
 
-[cobalt_porting_guide]: https://cobalt.dev/starboard/porting.html
-[dev_setup_linux]: https://cobalt.dev/development/setup-linux.html
+[cobalt_porting_guide]: https://developers.google.com/youtube/cobalt/docs/starboard/porting
+[dev_setup_linux]: https://developers.google.com/youtube/cobalt/docs/development/setup-linux
 [gn_check_tool]: https://cobalt.googlesource.com/third_party/gn/+/refs/heads/main/docs/reference.md#cmd_check
 [gn_doc_home]: https://cobalt.googlesource.com/third_party/gn/+/refs/heads/main/docs
 [gn_format_tool]: https://cobalt.googlesource.com/third_party/gn/+/refs/heads/main/docs/reference.md#cmd_format

cobalt/site/docs/gen/starboard/doc/c99.md

@@ -36,30 +36,38 @@ deprecated and eventually removed.
 ### <math.h>
 * acos
 * acosf
+* acosh
 * asin
 * asinf
+* asinh
 * atan
 * atan2
 * atan2f
 * atanf
+* atanh
 * cbrt
 * cbrtf
 * ceil
 * ceilf
 * cos
 * cosf
+* cosh
 * div
 * erf
 * erff
 * exp
 * expf
+* exp2
 * exp2f
 * fabs
+* fabsf
 * floor
 * floorf
+* fmaf
 * fmod
 * fmodf
 * frexp
+* ilogbf
 * isfinite
 * isnan
 * labs
@@ -80,17 +88,23 @@ deprecated and eventually removed.
 * nextafterf
 * pow
 * powf
+* remainder
 * round
 * roundf
 * scalbn
 * sin
 * sinf
+* sinh
 * sqrt
 * sqrtf
 * tan
 * tanf
+* tanh
 * trunc
 * truncf
+### <stdio.h>
+* sscanf
+* vsscanf
 ### <stdlib.h>
 * abs
 * atoi
@@ -134,3 +148,11 @@ deprecated and eventually removed.
 * wmemmove
 * wmemset
 * wcsncmp
+* snprintf
+* sprintf
+* vfwprintf
+* vsnprintf
+* vswprintf
+* ferror
+* fputwc
+* fwide

cobalt/site/docs/gen/starboard/doc/crash_handlers.md

@@ -35,7 +35,7 @@ const void* SbSystemGetExtension(const char* name) {
 }
 ```
 
-3. Calling the `third_party::crashpad::wrapper::InstallCrashpadHandler(bool start_at_crash)` hook
+3. Calling the `third_party::crashpad::wrapper::InstallCrashpadHandler()` hook
 directly after installing system crash handlers. On linux, for example, this
 could look like:
 
@@ -47,7 +47,8 @@ int main(int argc, char** argv) {
   starboard::shared::signal::InstallCrashSignalHandlers();
   starboard::shared::signal::InstallSuspendSignalHandlers();
 
-  third_party::crashpad::wrapper::InstallCrashpadHandler(true);
+  std::string ca_certificates_path = starboard::common::GetCACertificatesPath();
+  third_party::crashpad::wrapper::InstallCrashpadHandler(ca_certificates_path);
 
   int result = application.Run(argc, argv);
   ...

cobalt/site/docs/gen/starboard/doc/evergreen/cobalt_evergreen_lite.md

@@ -100,7 +100,6 @@ Cobalt Evergreen currently supports the following
 
 Target Architectures:
 
-*   `x86_32`
 *   `x86_64`
 *   `armv7 32`
 *   `armv8 64`

cobalt/site/docs/gen/starboard/doc/evergreen/cobalt_evergreen_overview.md

@@ -147,9 +147,9 @@ Evergreen:
         for more details.
 *   `kSbMemoryMapProtectExec`
     *   Ensures mapped memory can be executed
-*   `#define SB_CAN_MAP_EXECUTABLE_MEMORY 1`
+*   Set `kSbCanMapExecutableMemory` to `true`
     *   Specifies that the platform can map executable memory
-    *   Defined in `configuration_public.h`
+    *   Defined in `configuration_constants.h`
 
 Only if necessary, create a customized SABI configuration for your architecture.
 Note, we do not anticipate that you will need to make a new configuration for
@@ -306,8 +306,8 @@ instructions available [here](cobalt_evergreen_reference_port_raspi2.md).
 
 1. Build the `crashpad_database_util` target and deploy it onto the device.
 ```
-$ cobalt/build/gn.py -p <partner_port_name> -c qa
-$ ninja -C out/<partner_port_name>_qa crashpad_database_util
+$ gn gen out/<partner_port_name>_qa --args='target_platform="<partner_port_name>" build_type="qa"'
+$ ninja -C out/<partner_port_name>_qa native_target/crashpad_database_util
 ```
 2. Remove the existing state for crashpad as it throttles uploads to 1 per hour:
 ```
@@ -489,7 +489,6 @@ Image required for all slot configurations:
 │       └── cobalt <--(SLOT_0)
 │           ├── content <--(relative path defined in kSystemImageContentPath)
 │           │   ├── fonts <--(`empty` configuration)
-│           │   ├── (icu) <--(only present when it needs to be updated by Cobalt Update)
 │           │   ├── licenses
 │           │   ├── ssl
 │           ├── lib
@@ -510,15 +509,13 @@ updates in an example 3-slot configuration:
     ├── installation_2 <--(SLOT_2 - contains new Cobalt version)
     │   ├── content
     │   │   ├── fonts <--(`empty` configuration)
-    │   │   ├── (icu) <--(only present when it needs to be updated by Cobalt Update)
     │   │   ├── licenses
     │   │   ├── ssl
     │   ├── lib
     │   │   └── libcobalt.so <--(SLOT_2 version of libcobalt.so)
     │   ├── manifest.fingerprint
     │   └── manifest.json <-- (Evergreen version information of libcobalt.so under SLOT_2)
     ├── installation_store_<APP_KEY>.pb
-    └── icu (default location shared by installation slots, to be explained below)
 ```
 Note that after the Cobalt binary is loaded by the loader_app, `kSbSystemPathContentDirectory` points to the
 content directory of the running binary, as stated in Starboard Module Reference of system.h.
@@ -562,24 +559,6 @@ On Raspberry Pi the Cobalt fonts are configured the following way:
 <kSbSystemPathContentDirectory>/fonts
 ```
 
-### ICU Tables
-The ICU table should be deployed under the `kSbSystemPathStorageDirectory`. This
-way all Cobalt Evergreen installations would be able to share the same tables.
-The current storage size for the ICU tables is 7MB.
-
-On Raspberry Pi this is:
-
-```
-/home/pi/.cobalt_storage/icu
-```
-The Cobalt Evergreen package will not carry ICU tables by default but may add
-them in the future if needed. When the package has ICU tables they would be
-stored under the content location for the installation:
-
-```
-<SLOT_#>/content/icu
-```
-
 ### Handling Pending Updates
 Pending updates will be picked up on the next application start, which means
 that on platforms that support suspending the platform should check
@@ -609,9 +588,6 @@ behavior can be easily configured on a per-app basis with simple command-line fl
 The configurable options for Cobalt Updater configuration are:
 * `--evergreen_lite` *Use the System Image version of Cobalt under Slot_0 and turn
   off the updater for the specified application.*
-* `--disable_updater_module` *Stay on the current version of Cobalt that might be the
-  system image or an installed update, and turn off the updater for the
-  specified application.*
 
 Each app’s Cobalt Updater will perform an independent, regular check for new
 Cobalt Evergreen updates. Note that all apps will share the same set of slots,
@@ -640,7 +616,7 @@ existing slot. In this case, `APP_1` and `APP_2` are now using the same Cobalt
 binaries in SLOT_2.
 
 If `APP_3` has not been launched, not run through a regular Cobalt Updater
-check, or launched with the `--evergreen_lite`/`--disable_updater_module` flag,
+check, or launched with the `--evergreen_lite` flag,
 it stays with its current configuration.
 
 #### AFTER COBALT UPDATE
@@ -667,15 +643,14 @@ loader_app --url="<YOUR_APP_2_URL>"
 loader_app --url="<YOUR_APP_3_URL>"
 
 
-# Only APP_1 gets Evergreen Updates, APP_2 disables the updater and uses an alternate splash screen, APP_3 uses
+# APP_1 gets Evergreen Updates, APP_2 uses an alternate splash screen, APP_3 uses
 # the system image and disables the updater
 [APP_1] (Cobalt Updater ENABLED)
-[APP_2] (Cobalt Updater DISABLED)
+[APP_2] (Cobalt Updater ENABLED)
 [APP_3] (System Image loaded, Cobalt Updater DISABLED)
 
 loader_app --url="<YOUR_APP_1_URL>"
-loader_app --url="<YOUR_APP_2_URL>" --disable_updater_module \
---fallback_splash_screen_url="/<PATH_TO_APP_2>/app_2_splash_screen.html"
+loader_app --url="<YOUR_APP_2_URL>" --fallback_splash_screen_url="/<PATH_TO_APP_2>/app_2_splash_screen.html"
 loader_app --url="<YOUR_APP_3_URL>" --evergreen_lite
 
 

cobalt/site/docs/gen/starboard/doc/evergreen/cobalt_evergreen_reference_port_raspi2.md

@@ -5,9 +5,8 @@ Book: /youtube/cobalt/_book.yaml
 
 ## Requirements
 
-*   Raspberry Pi 2 (image configured per
-    [instructions](https://cobalt.dev/development/setup-raspi.html) on
-    cobalt.dev)
+*   Raspberry Pi environment setup per
+    [instructions](https://developers.google.com/youtube/cobalt/docs/development/setup-raspi).
 
 ## Build instructions
 

cobalt/site/docs/gen/starboard/doc/evergreen/symbolizing_minidumps.md

@@ -11,16 +11,41 @@ debugging, as these minidumps have the information for the dynamic
 `libcobalt.so` module correctly mapped, which a out-of-the-box dumper could not
 manage.
 
-## Obtaining the Tools to Symbolize Minidumps
+## Symbolizing with the Provided Docker Container (Recommended)
+
+We provide a docker container at `docker/crashpad_symbolize/Dockerfile` with a
+corresponding docker-compose service, `crashpad-symbolize`, with which you can
+symbolize your minidumps.
+
+Build and run the container with:
+
+```
+MINIDUMP_PATH=/path/to/minidump_file.dmp docker-compose up --build crashpad-symbolize
+```
+
+Where `MINIDUMP_PATH` is the path to your minidump file. The service will also
+pick up environment values for `GITHUB_TAG`, `ARCHITECTURE`, `SB_API_VERSION`,
+and `CONFIG`, so ensure these are correct.
+
+* `GITHUB_TAG`: A Cobalt version with an associated release, i.e. 25.lts.10
+* `ARCHITECTURE`: One of `x64`, `x86`, `arm64`, `arm-hardfp`, or `arm-softfp`
+* `SB_API_VERSION`: The Starboard version, i.e. `16`
+* `CONFIG`: One of `release` or `qa`
+
+## Symbolizing Locally
+
+If you wish, you can download all the necessary tools to locally symbolize
+minidumps. This is more work than doing it with the docker container.
+
+### Obtaining the Tools to Symbolize Minidumps
 
 Tools for symbolizing these dumps are available through
 [Breakpad](https://chromium.googlesource.com/breakpad/breakpad/). Breakpad is
 an open source crash reporting library that we use to obtain symbol files
 (`.sym`) from unstripped binaries, and to process the symbol files with the
 minidumps to produce human-readable stacktraces.
 
-
-### Building Breakpad
+#### Building Breakpad
 
 [Breakpad](https://chromium.googlesource.com/breakpad/breakpad/) provides
 instructions for building these tools yourself. The
@@ -54,7 +79,7 @@ building on Linux it will also build the `dump_syms` tool
 depot_tools from your `$PATH` environment variable, as it can conflict with
 Cobalt's depot_tools.
 
-## Symbolizing Minidumps
+### Symbolizing Minidumps
 
 Now that you have all the tools you need, we can symbolize the dumps. To be
 able to symbolize Cobalt using Evergreen, you need to be get the unstripped
@@ -100,7 +125,7 @@ $ /path/to/minidump_stackwalk /path/to/your/minidump.dmp symbols/
 `minidump_stackwalk` produces verbose output on stderr, and the stacktrace on
 stdout, so you may want to redirect stderr.
 
-### Addendum: Adding Other Symbols
+#### Addendum: Adding Other Symbols
 
 We can use the process above to add symbols for any library or executable you
 use, not just `libcobalt.so`. To do this, all you have to do is run the