Update 3 modules

[flathubbot]

Update chromium-117.0.5938.149.tar.xz to 118.0.5993.70 Update clang-llvmorg-18-init-1174-g2532b68f-1.tgz to 118.0.5993.70 Update llvm-project to 118.0.5993.70

🤖 This pull request was automatically generated by flathub/flatpak-external-data-checker. Please open an issue if you have any questions or complaints. 🤖

[flathubbot]

Started test build 72564

[flathubbot]

Build 72564 failed

[flathubbot]

Started test build 72653

[flathubbot]

Build 72653 was cancelled

[flathubbot]

Started test build 72655

[flathubbot]

Started test build 72663

[flathubbot]

Build 72655 failed

[flathubbot]

Build 72663 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/55316/org.chromium.Chromium.flatpakref

[StayPirate]

Hi @refi64, could you please enlighten me about how the flathub update process looks like from the moment a PR is merged to master until the update is actually available to users? I always noted hours-long delays and I have no clue about what happens during that time frame.

[refi64]

I always noted hours-long delays and I have no clue about what happens during that time frame.

The flow generally looks like this:

• A Chromium release happens.
• Google actually uploads the release tarball (sometimes this gets delayed by several hours or longer, but that's on upstream; I've looked into not using the tarball before but it was really tricky, though maybe with the recent submodules migration it might be easier...).
• Google also uploads the tarball for the Chromium toolchain. These often happen out-of-order; you'll notice sometimes the external data checker opens a PR that only updates the toolchain tarball because the main source tarball isn't up yet.
• The external data checker sees the new sources and opens an MR. Afaik it runs hourly? so this shouldn't add much delay.
• The build almost always fails due to a patch failing to apply (even if all of the others work, the FFmpeg configuration one will often fail and need to be regenerated).
• I reset and update my local copy of the source tree, apply the existing patches, and work through the conflicts. This usually doesn't take long, but sometimes changes will massively shift internals around and then applying the patches can take longer.
• For the FFmpeg configuration, it usually just needs to be re-generated from scratch. Sometimes the regeneration flow breaks in new and exciting ways, but usually this amounts to running a command and waiting.
• Once all the patches are updated, they're exported into the repo, and I push up the changes to the PR.
• After that, it's waiting on Flathub infra to attempt to build it, and then see if there are any other things that broke and need changes applied to fix (hopefully not at the very end lol, that's always a bit painful).
• If the build completes successfully, I install it and do some basic smoke tests. Assuming nothing goes wrong, it can be merged in. (If something does go wrong, then it's back to editing the patches or build scripts and restarting the process from there.)

Although this tends to take a hot minute, I try to get everything out in <48hr at worst; I think we've only passed that maybe once for a particularly nasty update.

[StayPirate]

Amazing, that's all very interesting! The full process is usually opaque for users and I really appreciate you spent some time to put light on the main phases of it.

Anyway, that doesn't fully answer my question: I'd like to understand what happen from when you merge the PR until the update appears to be available to users (via flatpak update). That's the part where I noticed hours-long delay. At that point the artifacts are already built and tested, so I would expect a bot to copy them to the Flathub repository after a short period of time (hourly maybe). Instead I usually got notified only after some hours.

FYI I have a custom script which runs flatpak update every five minutes and send me a notification as soon as an update is available. That's why I noticed that and I'm asking. Moreover, I noticed the same behavior happening for all the flatpak applications I use, that's not specific to Chromium.

[refi64]

Anyway, that doesn't fully answer my question: I'd like to understand what happen from when you merge the PR until the update appears to be available to users (via flatpak update).

Ohhhh 😅 yeah that's just from the rebuild. Iirc information on the build branch gets injected into the build environment, so flathub can't actually reuse the PR build result and has to rebuild again. The upload and publish process also takes a hot minute, because Chromium's debug info is really big.