Control: reopen -1 > Oh - now after I did a release without the feature-fencing patch, I > found the relevant build log: > https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-axum/47457177/log.gz
the most recent run at https://ci.debian.net/packages/r/rust-axum/testing/amd64/49206913/ failed in a similar way: 1738s autopkgtest [21:38:01]: test rust-axum-macros-0.3:default: -----------------------] 1738s autopkgtest [21:38:01]: test rust-axum-macros-0.3:default: - - - - - - - - - - results - - - - - - - - - - 1738s rust-axum-macros-0.3:default PASS 1738s autopkgtest [21:38:01]: @@@@@@@@@@@@@@@@@@@@ summary 1738s rust-axum-0.6:@ PASS 1738s rust-axum-0.6: FAIL non-zero exit status 101 1738s rust-axum-0.6:default PASS 1738s rust-axum-0.6:form FAIL non-zero exit status 101 1738s rust-axum-0.6:headers FAIL non-zero exit status 101 1738s rust-axum-0.6:http1 FAIL non-zero exit status 101 1738s rust-axum-0.6:http2 FAIL non-zero exit status 101 1738s rust-axum-0.6:json PASS 1738s rust-axum-0.6:macros FAIL non-zero exit status 101 1738s rust-axum-0.6:matched-path FAIL non-zero exit status 101 1738s rust-axum-0.6:multipart FAIL non-zero exit status 101 1738s rust-axum-0.6:original-uri FAIL non-zero exit status 101 1738s rust-axum-0.6:query FAIL non-zero exit status 101 1738s rust-axum-0.6:tokio FAIL non-zero exit status 101 1738s rust-axum-0.6:tower-log FAIL non-zero exit status 101 1738s rust-axum-0.6:tracing FAIL non-zero exit status 101 1738s rust-axum-0.6:ws FAIL non-zero exit status 101 1738s rust-axum-core-0.3:@ PASS 1738s rust-axum-core-0.3: PASS 1738s rust-axum-core-0.3:default PASS 1738s rust-axum-core-0.3:tracing PASS 1738s rust-axum-macros-0.3:@ PASS 1738s rust-axum-macros-0.3: PASS 1738s rust-axum-macros-0.3:default PASS After looking a bit more into axum, and after reading the conversation upstream, it seems to me that there is little appetite upstream for having the individual crates self-testable. In fact, this cannot work in the current form as some features, most notably the json feature, is not optional at all but in fact mandatory for the tests. That means that you would need to mark a whole lot of tests as dependent on the presence of indivudal features. That can be done by adding apppropriate feature annotations in the rust-axum test code, but given rust-axum is currently holding up migration of other packages (such as rust-tonic and aardvark-dns), I would like to repeat my recommendation to disable those autopkgtests that trigger "--no-default-features". I'm currently traveling and cannot focus on this issue as much as I would like to at the moment. I also don't see any issue in the actual upstream code; rather the issue is with the tests. As such, I honestly beleive that for the time being, disabling those tests doesn't loose us coverage, but to the contrary, is an impediment of finding other, real issues in the code by using it from application code that actually needs it in the wild.
