Skip to content

Many patches for stderr#5439

Merged
cgwalters merged 4 commits intocoreos:mainfrom
cgwalters:revert-merge
Jul 29, 2025
Merged

Many patches for stderr#5439
cgwalters merged 4 commits intocoreos:mainfrom
cgwalters:revert-merge

Conversation

@cgwalters
Copy link
Member

@cgwalters cgwalters commented Jul 29, 2025

This reverts commit f4aecb9.
It causes ill-defined behavior with older glib, resulting in
file descriptor mis-assignments.

Also add tests that verify that we do get both stdout and stderr from both postprocess scripts and package scripts.

Closes: #5436

This reverts commit f4aecb9.
It causes ill-defined behavior with older glib, resulting in
file descriptor mis-assignments.
Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request reverts a problematic change and adds thorough testing to prevent future regressions. The new tests for bwrap's stdout/stderr handling are a great addition. I have a couple of minor suggestions for the new test scripts to improve consistency and conciseness.

This was a regression from
057ccd9

Signed-off-by: Colin Walters <walters@verbum.org>
This backs out prior changes to use `.run()` in most
cases where we're invoking nontrivial commands.

Yeah, the `run` API here is probably too much of a trap and
we should go back to not swallowing stderr. Or at least have
very explicit APIs for the two cases.

Signed-off-by: Colin Walters <walters@verbum.org>
@cgwalters
Copy link
Member Author

/gemini review

@cgwalters cgwalters changed the title Revert "rust/bwrap: don't swallow STDERR when running commands" Many patches for stderr Jul 29, 2025
@cgwalters cgwalters marked this pull request as ready for review July 29, 2025 18:39
Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request reverts a change that merged STDERR and STDOUT for command execution in bwrap, which caused issues with older glib versions. The revert is accompanied by updates to error handling to accommodate separate output streams and new tests to verify that both STDOUT and STDERR are correctly captured. The changes look good overall. I've added a few minor suggestions to improve the consistency of error messages across the modified files.

This was referenced Jul 29, 2025
@cgwalters cgwalters requested a review from jmarrero July 29, 2025 19:01
Copy link
Member

@jmarrero jmarrero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

cgwalters added a commit to cgwalters/bootc that referenced this pull request Jul 29, 2025
There really isn't any kind of single default way to run a subprocess,
that's why it's tricky. Sometimes one wants to have them be async,
sometimes synchronous. Sometimes one wants to capture stdout,
other times not etc.

The `run()` name implies it's a default but it can't really be
because some use cases we really do want to directly copy
stderr instead of capturing it.

It happens that *most* cases here inside bootc we're fine
to only show stderr on error I think; I only changed the editor
case to use the new `run_inherited()`.

But in contrast many use cases in e.g.
coreos/rpm-ostree#5439
wanted `run_inherited()`.

Unit tests: Assisted-by: Claude Code
Signed-off-by: Colin Walters <walters@verbum.org>
cgwalters added a commit to cgwalters/bootc that referenced this pull request Jul 29, 2025
There really isn't any kind of single default way to run a subprocess,
that's why it's tricky. Sometimes one wants to have them be async,
sometimes synchronous. Sometimes one wants to capture stdout,
other times not etc.

The `run()` name implies it's a default but it can't really be
because some use cases we really do want to directly copy
stderr instead of capturing it.

It happens that *most* cases here inside bootc we're fine
to only show stderr on error I think; I only changed the editor
case to use the new `run_inherited()`.

But in contrast many use cases in e.g.
coreos/rpm-ostree#5439
wanted `run_inherited()`.

Unit tests: Assisted-by: Claude Code
Signed-off-by: Colin Walters <walters@verbum.org>
@cgwalters cgwalters enabled auto-merge July 29, 2025 20:52
@cgwalters
Copy link
Member Author

/override ci/prow/fcos-e2e
At some point we should drop Prow since it's not doing much that isn't covered elsewhere.

@openshift-ci
Copy link

openshift-ci bot commented Jul 29, 2025

@cgwalters: Overrode contexts on behalf of cgwalters: ci/prow/fcos-e2e

Details

In response to this:

/override ci/prow/fcos-e2e
At some point we should drop Prow since it's not doing much that isn't covered elsewhere.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@cgwalters cgwalters merged commit 4e962b1 into coreos:main Jul 29, 2025
18 of 20 checks passed
cgwalters added a commit to cgwalters/bootc that referenced this pull request Jul 29, 2025
There really isn't any kind of single default way to run a subprocess,
that's why it's tricky. Sometimes one wants to have them be async,
sometimes synchronous. Sometimes one wants to capture stdout,
other times not etc.

The `run()` name implies it's a default but it can't really be
because some use cases we really do want to directly copy
stderr instead of capturing it.

It happens that *most* cases here inside bootc we're fine
to only show stderr on error I think; I only changed the editor
case to use the new `run_inherited()`.

But in contrast many use cases in e.g.
coreos/rpm-ostree#5439
wanted `run_inherited()`.

Unit tests: Assisted-by: Claude Code
Signed-off-by: Colin Walters <walters@verbum.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

EBADF in scripts (ppc64le)

3 participants