You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I get this output for cargo test --target=aarch64-unknown-linux-gnu, which I don't get when running via x86_64 normally:
---- process::tests::handle_external_command_not_executable stdout ----
thread 'process::tests::handle_external_command_not_executable' panicked at src/test_helpers/assertions/assert_results.rs:98:5:
assertion failed: `(left == right)`
Diff < left / right > :
<[
< Error(Unable to run /work/build/makepkg/git-interactive-rebase-tool/src/git-interactive-rebase-tool/test/not-executable.sh : File not executable: /work/build/makepkg/git-interactive-rebase-tool/src/git-interactive-rebase-tool/test/not-executable.sh, Some(List)),
<]
>[]
---- process::tests::handle_external_command_not_found stdout ----
thread 'process::tests::handle_external_command_not_found' panicked at src/test_helpers/assertions/assert_results.rs:98:5:
assertion failed: `(left == right)`
Diff < left / right > :
<[
< Error(Unable to run /work/build/makepkg/git-interactive-rebase-tool/src/git-interactive-rebase-tool/test/not-found.sh : File does not exist: /work/build/makepkg/git-interactive-rebase-tool/src/git-interactive-rebase-tool/test/not-found.sh, Some(List)),
<]
>[]
failures:
process::tests::handle_external_command_not_executable
process::tests::handle_external_command_not_found
I'm not quite sure if this indicates a bug in this program or a shortcoming of some dependency's implementation, but I don't know enough about the way the tool is designed to tell. Right now I'm running these tests via qemu rather than actual hardware, but I assume it shouldn't make a difference.
Apologizes for taking some time to get back to you on this one.
These two tests are testing error responses for launching the external editor, I wonder if there is something with the fixture files that is causing a failure.
For process::tests::handle_external_command_not_executable, the path <project-root>/test/not-executable.sh should exist and not be executable.
For process::tests::handle_external_command_not_found, the path <project-root>/test/not-found.sh should not exist.
The project is built against aarch64, but currently only runs the tests on x86-64. I assumed, at least for this project, that they would be equivalent. Though it's probably worth running the tests against aarch64 as well.
Yeah, I did find it very strange that these particular test failures only happened on aarch64; it didn't look like anything architecture-specific, as you mentioned.
It's entirely possible this is a qemu bug also, since I was running via qemu instead of natively. But the test failure was just bedazzling so I decided to report it, and it might have been a weird timing issue also.
Repository owner locked and limited conversation to collaborators on Jun 8, 2025
Activity
MitMaro commentedon May 29, 2025
Apologizes for taking some time to get back to you on this one.
These two tests are testing error responses for launching the external editor, I wonder if there is something with the fixture files that is causing a failure.
For
process::tests::handle_external_command_not_executable, the path<project-root>/test/not-executable.shshould exist and not be executable.For
process::tests::handle_external_command_not_found, the path<project-root>/test/not-found.shshould not exist.The project is built against aarch64, but currently only runs the tests on x86-64. I assumed, at least for this project, that they would be equivalent. Though it's probably worth running the tests against aarch64 as well.
MitMaro commentedon May 29, 2025
I just ran the tests against the GitHub ARM-based runners and the tests passed successfully.
I believe that GitHub uses their Apple ARM machines to host their Linux (Ubuntu) based aarch64 runners.
clarfonthey commentedon May 29, 2025
Yeah, I did find it very strange that these particular test failures only happened on aarch64; it didn't look like anything architecture-specific, as you mentioned.
It's entirely possible this is a qemu bug also, since I was running via qemu instead of natively. But the test failure was just bedazzling so I decided to report it, and it might have been a weird timing issue also.