Hello all. At long last, I've had an opportunity to read up on / experiment with OBS, and have put together a design proposal for a release-automation system to replace the current implementation and practice in this repo.

One important difference is that the new approach will be fully automated, requiring no manual intervention except when occasional patch/dependency conflicts arise. Another is that it uses the Debian adaptation of the Chromium source as the starting point, rather than the original Google upstream. (This relieves us of the burden of adapting Chromium to Debian, which the Debian package maintainers already do.)

The entire process begins with an e-mail notification from Debian, indicating that a new version of their chromium package has been released, and ends with corresponding binary u-c packages in the OBS download areas. Here is an overview:

1. tracker.debian.org sends out a chromium source-upload notification to an e-mail address that we have previously subscribed on the site. The message looks like this.

2. Because (as I understand) we cannot initiate a GitHub Action with an arbitrary e-mail message, we have the message sent to a service like ProxiedMail where we can make it trigger a webhook.

   (This can also be done with GMail, but I think everyone will agree that would not be a good idea.)

3. The webhook kicks off the GitHub Action here.

4. The GitHub Action downloads the newly-minted chromium source package from the Debian repos, either incoming.debian.org (for unstable uploads) or security.debian.org (stable security updates). This consists of three files: an ~800 MB .orig.tar.xz original source tarball, a .debian.tar.xz "debianization" tarball, and a .dsc source control file. The source package PGP signature and checksums are verified.

5. The GitHub Action downloads the latest u-c-debian source-conversion framework, and the u-c repo proper. If the latter does not have a commit matching the Debian package's upstream-source version, then the process stops---to be re-started later at this step when u-c is updated.

   (There would also be entry points at this step to allow for fixes to u-c and/or u-c-debian, as needed.)

6. The GitHub Action unpacks the sources, applies the u-c source conversion, and builds a new source package from the result. (Note that the .orig.tar.xz file remains exactly the same; all the necessary changes are in the other two files.)

   The newly-created source package should be signed, although how the signing key should be managed in the secrets framework remains to be determined.

7. (Optional) The GitHub Action performs a partial test build of the package. This is no more than initiating a build, and letting it run for e.g. twenty minutes. If the build is still going at the end of that time, then it is stopped and the test passes. This is intended to catch the significant portion of build issues that occur early on in the process.

8. The GitHub Action posts the newly-created .debian.tar.xz and .dsc files as a release. (The .orig.tar.xz file is not posted, not only because it's huge, but also because we didn't modify it.)

9. The GitHub Action prepares and pushes a new _service file to OBS. This file invokes the download_url and verify_file services for the three source package files: the .orig.tar.xz file is downloaded from Debian, and the other two are downloaded from the GitHub release area. SHA-256 hashes are provided and verified for all three.

10. Once OBS has the three source-package files, it begins the build. If and when the build completes successfully, OBS will post the new binary packages for user download.

I wanted to put together a prototype of this, but unfortunately, my fork of this repo does not appear to have access to a GitHub runner. I do have a test build up on OBS, which was helpful in verifying how some aspects of the service work. And I have a similar process to the above already up and running for three browser packages on the XtraDeb PPA repo: regular chromium, firefox, and ungoogled-chromium.

Note that Debian has at least two separate tracks for chromium uploads: unstable/sid, and stable (currently bookworm). Until recently, oldstable (bullseye) was also supported. I think we should provide builds for all tracks supported by Debian, as different users may have one over the other installed.

This would mean, however, that it isn't enough for the ungoogled-chromium OBS project to have just an ungoogled-chromium-debian area; we would need e.g. ungoogled-chromium-debian-bookworm and ungoogled-chromium-debian-unstable. (Because the OBS project already provides the "ungoogled-chromium" context, I would also advise dropping that prefix from the names of the OBS package areas.)

Also, because the Raspbian package sources are identical to Debian's, adding builds for that distro from the same source is basically a freebie. (Debian itself has a half-dozen other architectures that could be enabled as well, though that should probably be driven by user demand. I'm not clear on the exact differences between Debian's armv7l support versus Rasbian's, but I figure most RaspberryPi users will want the latter.)

One additional wrinkle: It will be necessary to set up a subproject providing some build dependencies. At this time, the chromium package for stable lists rustc-web as a build-dep, yet that package does not appear in the Debian package indexes. And the reason for that is explained here: the package is currently being served from stable-proposed-updates, likely until the next point release.

Normally, a requirement like this should be covered by an additional repository path in the OBS Debian_12 download-on-demand area. But OBS currently offers only three options there: standard, update, and backports. None of which provide rustc-web at present.

I e-mailed the listed project maintainers about this, but have received no response. So our only alternative is to download and build rustc-web ourselves, as I did here. (If anyone knows of a better way to bring this issue to SUSE's attention, please let me know.)

Lastly, please note that I have not forgotten about Ubuntu support. It is trickier to address, however, because it involves a non-trivial Debian-to-Ubuntu conversion step that is outside the scope of the u-c project. So I will bring it up once the Debian side is sorted out.

Thoughts? @networkException @Eloston @PF4Public