https://bugzilla.redhat.com/show_bug.cgi?id=2281965 --- Comment #5 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- (In reply to Fabio Valentini from comment #4) > I took a quick look at the test failures. > > On i686, it looks like it's failing to allocate 1.6 GB in the doctest that > adds the current directory (".") into a tar archive. > This likely includes the "target" directory, so any compiled artifacts > generated during %cargo_build and %cargo_test. > This is likely working *most of the time*, but it's maybe not a good idea in > general. > > see https://github.com/vorot93/tokio-tar/blob/master/src/builder.rs#L400 This is a logical explanation, although something still isn’t *entirely* adding up—when I tested this in an fedora-rawhide-i386 mock chroot, the target directory was only 303M, so this allocation still seems bizarrely large. Would be nice if upstream had a bug tracker. Still, an arch-dependent or even unconditional test skip is probably the way to go here regardless of what is going on. The only reason to build i686 is to avoid having to propagate ExcludeArch, not to actually *use* it. > > On s390x, I can't really tell what's going wrong. The error message isn't > that helpful because the test just "assert!(entries.next().await.is_none()" > instead of using "assert_eq!(entries.next().await, None)", which would print > the value that is "not none" in the error message instead of just saying "I > wanted a true, but I got a false! FAIL"). Is the failure persistent? It > might just have been a fluke. > > see https://github.com/vorot93/tokio-tar/blob/master/tests/all.rs#L1103 Good question. I just kicked off five scratch builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=118005832 https://koji.fedoraproject.org/koji/taskinfo?taskID=118005833 https://koji.fedoraproject.org/koji/taskinfo?taskID=118005834 https://koji.fedoraproject.org/koji/taskinfo?taskID=118005842 https://koji.fedoraproject.org/koji/taskinfo?taskID=118005845 The test didn’t fail on s390x again, but it did fail twice on aarch64 with similar output: failures: ---- insert_local_file_different_name stdout ---- thread 'insert_local_file_different_name' panicked at tests/all.rs:1103:5: assertion failed: entries.next().await.is_none() note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace failures: insert_local_file_different_name test result: FAILED. 50 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.05s error: test failed, to rerun pass `--test all` Running `/builddir/build/BUILD/tokio-tar-0.3.1/target/rpm/deps/entry-5ef2d6d85a16be6a` …and one of those times, two other tests failed as well: failures: ---- insert_local_file_different_name stdout ---- thread 'insert_local_file_different_name' panicked at tests/all.rs:1103:5: assertion failed: entries.next().await.is_none() ---- large_filename stdout ---- thread 'large_filename' panicked at tests/all.rs:195:5: assertion `left == right` failed left: 0 right: 4 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ---- writing_files stdout ---- thread 'writing_files' panicked at tests/all.rs:160:5: assertion `left == right` failed left: 0 right: 4 failures: insert_local_file_different_name large_filename writing_files test result: FAILED. 48 passed; 3 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.05s As I just wrote in https://github.com/astral-sh/uv/issues/3423#issuecomment-2123668288, It looks like the `insert_local_file_different_name` is flaky, roughly less than 20% of the time, on `s390x`, but it also occurs (more frequently) on `aarch64`. I have also observed flaky failures in other tests on `aarch64` – at least `large_filename` and `writing_files`, and my notes indicate that I saw `path_separators` panic in a previous attempt. I think a reasonable conclusion here is that `tokio-tar` has significant race conditions, at least on some architectures, and should have engaged in much more fearful concurrency. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2281965 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202281965%23c5 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
