[cgwalters-bot]

Library code that writes straight to stdout/stderr is easy to add and hard to spot in review. It also bypasses --progress-fd, so anything consuming the progress API never sees bootc's status output. This came up in bootc-dev#2449 (comment), where a stray println!() slipped into the composefs pull path ("We may need a blanket ban on (e)println! in crates/lib").

This series sends human-facing status through the progress API, then denies clippy::print_stdout and clippy::print_stderr in bootc-lib.

The progress protocol gets a generic Message event ({"type":"Message","level":"info"|"warning","text":"..."}). ProgressWriter::message() (and its info()/warning() shorthands) prints the text exactly as before, info to stdout and warnings to stderr. If a progress fd is attached, it also sends the event. So output without --progress-fd doesn't change, and ProgressWriter::default() works as a plain printer for commands that don't take the flag. Adding an event type can break consumers that match strictly on type, so the protocol goes to 0.2.0, and the docs now say that unknown event types must be ignored.

To keep each step reviewable and rebase-friendly, the conversion is split into small commits, and each one builds on its own:

1. lib: write command results (digests, JSON, tables, GC stats) to an explicit stdout writer
2. lib/fsck: write passing checks to the writer fsck() is given
3. progress_jsonl: make ProgressWriter usable from sync code (std mutex, blocking writes). Tokio used to set O_NONBLOCK on the fd; this now clears it. The CLI runs a single-threaded runtime, so a --progress-fd reader that stops reading now stalls the whole process. Any writable fd is accepted now, not just a pipe, and the help text says so.
4. progress_jsonl: add the Message event and message(), bump to 0.2.0, update the schema and docs, and have the booted pushpull-upgrade tmt test check for Message events; the first user is the staging summary
5. deploy: pull "No changes", prune and fstab status
6. rollback: ostree and composefs
7. cli: upgrade, switch (including --mutate-in-place) and edit (upgrade/switch pass their --progress-fd writer)
8. composefs: update, switch, soft-reboot, usr-overlay
9. install: keep a ProgressWriter in State, convert install.rs (red warnings keep their highlighting and are also sent as events)
10. install: the helpers under install/ (block setup, config, completion), and the non-empty target warning of install mount
11. bootloader
12. boundimage
13. image: push and set-unified
14. task: task descriptions and command lines
15. lib: deny clippy::print_stdout/print_stderr at the crate root

Only a few direct prints are left, each with a targeted #[expect(..., reason = ...)]: global_init() runs before tracing is set up, journal_send() and the progress writer report that they themselves are failing, the spinner has a plain-text fallback when there's no tty, and medium_visibility_warning() colors its warning for the terminal (and also sends it as an event). Tests are exempt via allow-print-in-tests in clippy.toml.

The ban uses the print_stdout/print_stderr restriction lints, denied by a bootc-lib crate attribute. This scopes it to that crate: the root clippy.toml is shared by the whole workspace, and a crates/lib/clippy.toml would replace the root config rather than extend it. anstream's print macros aren't covered by those lints, so they're listed in disallowed-macros in clippy.toml, and only bootc-lib denies that lint (it's also the only crate using them).

Not in this PR: install (to-disk/to-filesystem/to-existing-root) and rollback still don't take --progress-fd. With this series, adding it only means passing the fd to prepare_install(), or to the writer rollback already creates. Task and the anaconda/ostree completion paths also use a plain printing writer for now, and the output of child processes (e.g. Task commands, bootupctl) still goes straight to the inherited stdout/stderr.

Other possible follow-ups:

• Harden the progress fd against a stalled reader, e.g. make it non-blocking and drop lossy events on EAGAIN (with a poll or timeout for required ones).
• Message texts keep existing prefixes like warning: ... and notice: ... so the terminal output stays identical, which means the JSON text can repeat the level. I'd rather not strip them ad hoc. If we want bare text later, message() should add the warning: prefix itself based on the level and send the bare text in the event. notice: is info-level, so that prefix carries its own meaning.

Testing

Rebased onto main b06e0b0 (c47ebf9). The rebase was clean, apart from one real conflict: bootc-dev#2483 added an eprintln! warning to install mount (crates/lib/src/mount.rs), which the new deny rejected. That warning now goes through a ProgressWriter (squashed into the install helpers commit). The experimental-progress-fd.md edit follows the bootc-dev#2508 rename to bootc-experimental-progress-fd.7.md. At c47ebf9, on a 16-core devspace (cgwalters-devspace-36601734885, CentOS Stream 10 base):

• just validate and just unit-tests (465 passed) passed. validate's clippy run (-A clippy::all, CI's config) warns that the disallowed_macros expectation on medium_visibility_warning() is unfulfilled; that isn't new with the rebase.
• just test-tmt plan-20-image-pushpull-upgrade passed, including the new check for Message events on the progress fd.

Before the rebase, on a 16-core RHEL 10 devspace:

On a 16-core RHEL 10 devspace:

• For each commit: cargo check -p bootc-lib --all-targets (no warnings) and cargo test -p bootc-lib --lib.
• The tmt test change is checked for syntax (nu --ide-check), and the filter logic was run against sample JSONL (passes with a Message event, fails without one). I haven't run it in a VM.
• At the head: make validate (fmt, cargo test --no-run, --no-default-features checks, clippy with CI's flags, cargo doc with -D warnings), clippy with -D unfulfilled_lint_expectations, and cargo xtask update-generated {direct,from-code} --check. I also added a stray println!() and a stray anstream::eprintln!() to check that clippy rejects them.

Apart from plan-20 above, I haven't run the integration tests (tmt/VM). The terminal output is meant to be byte-for-byte unchanged.

Caveats

• This touches a lot of crates/lib, mostly one-line println! → prog.info() swaps. Because the commits are split by subsystem, a conflict should only affect one of them.

Generated-by: https://github.com/cgwalters/#llms

---

Review draft in cgwalters-forge, not upstream yet. This section is removed when the PR is opened upstream.

• Upstream: bootc-dev/bootc, base main
• Board item: PVTI_lADOE9oHIs4BlJLczg9kEIg
• Fork CI: off; the devspace testing described above is this PR's CI, and upstream CI runs once it is opened there

To review:

• Approve, or comment /promote on a line of its own, to open it upstream, ready for review. Either covers only the commits pushed so far.
• If upstream requires DCO, approving also signs off: promote adds Signed-off-by: Colin Walters <walters@verbum.org> to the commits lacking it (the bot's and yours; anyone else's only if you ask), with you as committer.
• Add a /draft line (in the same comment or before) to open it upstream as a draft (/ready undoes that).
• Close to drop it.
• Edit the title and description freely: they become the upstream PR's. Review comments are squashed into the commits they concern, with a reply here.

[cgwalters]

What I'm thinking here is we should try to go all-in on the progress API, so basically we have a generic "message" event or so, then we're drinking our own champagne

[cgwalters-bot]

Makes sense. Proposed design:

• Event: add Event::Message { level: Info|Warning, text }, serialized as {"type":"Message","level":"info","text":"..."}. Consumers that match on type strictly will see a new variant. So I'd bump API_VERSION to 0.2.0, regenerate progress-v0.schema.json, and say in experimental-progress-fd.md that unknown types must be ignored.

• Rendering: ProgressWriter::message(level, text) prints the text exactly as today (info to stdout, warning to stderr, via indicatif's println while pull bars are active). If an fd is attached, it also emits the JSONL event. So non-JSONL output stays the same, and JSONL mode additionally gets the events.

• Getting a writer to call sites: this is where I'd like your call. Only upgrade, switch and install reset take --progress-fd today, and they cover about 30 of the ~90 cli_status!/cli_warn! sites. The rest are in install/to-disk, bootloader, rollback, baseline, fsck and edit, and many of them are sync, while ProgressWriter::send is async (tokio mutex and pipe). Options:

  • A) Explicit threading (my recommendation; it's the "all-in" version). A prep commit makes ProgressWriter usable from sync code (std mutex, blocking writes; events are tiny and rate-limited). Then &ProgressWriter is passed down, stored in install's State. Commands without --progress-fd pass ProgressWriter::default(), which just prints. It's a larger diff, but it's greppable and has no hidden state.
  • B) A process-global sink, set once in cli.rs after parsing --progress-fd. cli_status! would emit through it. It's a much smaller diff, but it's ambient state, and the macros stay.

  Separately: should install and rollback grow --progress-fd now, or later?

I'll hold until you pick A or B. With A, I'd restructure the commits as follows: make ProgressWriter sync-capable, add Message, convert the call sites, then deny.

Generated-by: https://github.com/cgwalters/#llms

[cgwalters]

Option A though let's try to break this up into separate commits that at least compile check, not one big likely to conflict-fest "thread progress writer through everywhere"

[cgwalters-bot]

Done, with option A as 15 small commits. Each one passes cargo check -p bootc-lib --all-targets with no warnings, plus the bootc-lib unit tests, on its own:

• lib, lib/fsck: the two existing prep commits (command results to an explicit stdout writer)
• progress_jsonl: make ProgressWriter usable from sync code (std mutex + blocking writes)
• progress_jsonl: add Event::Message { level, text } and ProgressWriter::message()/info()/warning(). These print the same text as before and also send the event when an fd is attached. The protocol goes to 0.2.0, the schema is regenerated, and the docs say that consumers must ignore unknown event types.
• one commit each for deploy, rollback, cli (upgrade/switch/edit), composefs, install (writer kept in State), install/* helpers, bootloader, boundimage, image, task
• lib: deny clippy::print_stdout/print_stderr, with four justified #[expect]s (global_init, journal_send, the progress writer's own error path, the spinner's no-tty fallback)

Output without --progress-fd is unchanged. Commands that don't take the flag use ProgressWriter::default(), which just prints.

For the ban I kept the crate-level restriction lints instead of disallowed-macros, because clippy.toml applies to the whole workspace.

Deferred (not in this PR): --progress-fd for install and rollback. Adding it now only means passing the fd to prepare_install() or to the writer rollback already creates. Task and the anaconda/ostree completion entry points also still use a plain printing writer.

Tested on a 16-core devspace. At the head I ran make validate, clippy with -D unfulfilled_lint_expectations, and cargo xtask update-generated {direct,from-code} --check, and checked that a stray println!() fails clippy. I didn't run tmt/VM tests.

Generated-by: https://github.com/cgwalters/#llms

[cgwalters-bot]

Pushed a follow-up round (head 973e510b). The changes are squashed into the commits they belong to:

• sync ProgressWriter: the commit message now says that the CLI runtime is single-threaded, so a --progress-fd reader that stops reading stalls the whole process. It also says that tokio used to set O_NONBLOCK on the shared file description and we now clear it. The pipe check is gone, so the --progress-fd help text now just says "typically the write end of a pipe". The progress tests note that the pipe must not fill up, since the sender and the reader share a thread.
• Message event: test-image-pushpull-upgrade.nu now filters Message events out before checking events by position, and asserts that at least one Message event is there. I checked it with nu --ide-check and against sample JSONL but haven't run it in a VM.
• cli: switch --mutate-in-place now uses its --progress-fd writer.
• install: the ----- separator lines go only to the terminal (stderr) and are no longer sent as warning events.
• deny: anstream::{print,println,eprint,eprintln} are now in disallowed-macros, and only bootc-lib denies that lint (it's also the only crate using them). medium_visibility_warning has a justified #[expect].
• PR body: I fixed the reasoning for using crate-level lints (a crates/lib/clippy.toml would replace the root config, not extend it). I also noted that Task/child process output still goes to the inherited stdout, and listed hardening against a stalled reader (EAGAIN/poll) as a possible follow-up. On the prefix question, the recommendation is not to strip prefixes ad hoc: if we want bare text later, message() should add warning: itself based on the level. notice: is info-level, so that prefix carries its own meaning.

I re-ran the checks on a 16-core devspace. Every commit passes cargo check -p bootc-lib --all-targets with no warnings, and the unit tests pass (271 passed, 1 ignored). At the head, these all pass: make validate, clippy with CI's flags plus -D unfulfilled_lint_expectations, update-generated {direct,from-code} --check and cargo fmt --check. A stray println!() or anstream::eprintln!() fails clippy.

Generated-by: https://github.com/cgwalters/#llms

[cgwalters-bot]

Fix round 1 of 2 for c47ebf944276: run.

Generated-by: https://github.com/cgwalters/#llms

[cgwalters-bot]

✅ dispatch ended well. Result: #1

[cgwalters-bot]

The poll stopped following this pull request: a draft with no checkpoint; mark it ready if the work is complete. It is labelled needs-human; remove the label to have the poll start again on it, with fresh fix rounds.

Generated-by: https://github.com/cgwalters/#llms