RPM Support & Workflow

[syslogic]

Meanwhile the workflow builds 3 packages, but fails to install, because it currently cannot build the base package. Yesterday it was because of libzip, today something else. At least it displays a warning message, when listing the directory after the build.

Also, rhel-integration and rhel-orchestration Dockerfile seemingly cannot find the restored .rpms directory, when running on GitHub (not so locally), even when downloading them to the expected location <repo dir>/.rpms. Still need to find a way, how to make this work locally and remotely. These preinstall.sh are also not too well tested, as I need Linux with drive-space for that; meant for creating rhel-integration and rhel-orchestration images locally, with docker buildx.

Somehow I could not make common shell string-substitution work; that's why the uploaded artifact-name currently is not all lower-case anymore; I might still revert to passing the name as input, as I had it before (clunky, but functional).

[syslogic]

Meanwhile the artifact-name is all lower-case and I've added the missing libaom-devel and opus-devel build dependencies.
The uploaded artifacts had to be restored into the Dockerfile context, in order to be found by COPY. Still cannot get past:

ERROR: /home/runner/.cache/bazel/_bazel_runner/86f178b9c1d3fcfc19d53fc31f093d50/external/libzip+/BUILD:19:6: output 'external/libzip+/libzip/lib/libzip.a' was not created
ERROR: /home/runner/.cache/bazel/_bazel_runner/86f178b9c1d3fcfc19d53fc31f0[93](https://github.com/syslogic/android-cuttlefish/actions/runs/14428788120/job/40461155109#step:6:94)d50/external/libzip+/BUILD:19:6: Foreign Cc - CMake: Building libzip failed: not all outputs were created or valid
[8,241 / 11,352] Linting //cuttlefish/host/commands/acloud_translator:acloud_translator with clang-tidy; 6s processwrapper-sandbox ... (3 actions running)
ERROR: /home/runner/android-cuttlefish/base/cvd/cuttlefish/host/commands/host_bugreport/BUILD.bazel:27:16 Middleman _middlemen/cuttlefish_Shost_Scommands_Shost_Ubugreport_Scvd_Uinternal_Uhost_Ubugreport_Uclang_Utidy.lint_Utest.sh-runfiles failed: not all outputs were created or valid
ERROR: Build did NOT complete successfully

---

This seems to be a bug: bazelbuild/bazel-central-registry#3100

WARNING: For repository 'zlib', the root module requires module version [email protected],
but got [email protected] in the resolved dependency graph.

Please update the version in your MODULE.bazel or set --check_direct_dependencies=off

While there's ...

• https://registry.bazel.build/modules/zlib/1.3.1.bcr.3
• https://registry.bazel.build/modules/zlib/1.3.1.bcr.4

I've tried patching zlib from 1.3.1.bcr.3 to 1.3.1.bcr.4:

SEARCH='bazel_dep(name = "zlib", version = "1.3.1.bcr.3")'
REPLACE='bazel_dep(name = "zlib", version = "1.3.1.bcr.4")'
cat "${CVD_DIR}/MODULE.bazel" | sed -e "s/${SEARCH}/${REPLACE}/" > "${CVD_DIR}/MODULE.patched"
mv "${CVD_DIR}/MODULE.patched" "${CVD_DIR}/MODULE.bazel"
echo "RHEL patch: base/cvd/MODULE.bazel changed from [email protected] to [email protected]"
rm "${CVD_DIR}/MODULE.bazel.lock"
echo "RHEL patch: base/cvd/MODULE.bazel.lock also removed"

Then it does not show the warning anymore, but the result is still the same:

ERROR: /home/runner/.cache/bazel/_bazel_runner/86f178b9c1d3fcfc19d53fc31f093d50/external/libzip+/BUILD:19:6: output 'external/libzip+/libzip/lib/libzip.a' was not created
ERROR: /home/runner/.cache/bazel/_bazel_runner/86f178b9c1d3fcfc19d53fc31f093d50/external/libzip+/BUILD:19:6: Foreign Cc - CMake: Building libzip failed: not all outputs were created or valid

---

File cuttlefish-base-1.4.0-1.el9.aarch64.rpm also is not being built.
Not sure if this part is broken or just kind of neglected and untested?
This already fails at bazel config ded86c7, lacking ARM support.

[Databean]

Hi @syslogic ,

The difficulty in supporting a RPM build from our side is that we're mostly set up with debian and debian derivatives like ubuntu in our developer workstations and existing CI environments so we're not set up to iterate against failures that come up in this process.

Something we're considering but haven't committed to yet is inverting our current setup of debuild invoking bazel to instead lift the bazel workspace above the debian build scripts and use bazel's rules_pkg / pkg_deb targets to create .deb files as bazel build artifacts. This same set of utilities also has a pkg_rpm rule for creating .rpm files.

It's not the same as us locally developing against a redhat-derived distro, but it does mean that on our workstations we could theoretically have a single bazel build '//...' command from one bazel workspace produce the .deb and .rpm artifacts for both builds and report errors immediately on a packaging failure.

Does this sound interesting at all, and do you have a sense of how much of the work you've already put in would carry over to this strategy?