Hi Paul, On Mon, Jul 29, 2024 at 07:05:35AM +0200, Paul Gevers wrote: > Hi Julian, > > On 28-07-2024 11:10, Julian Gilbey wrote: > > It's failing the autopkgtest on riscv64 quite badly. It's a new > > package, and I have no idea where in the toolchain the problem lies; > > given that pytest also fails on this architecture, it's probably not > > pytest-jupyter itself that is problematic. It's also quite probable > > that all of the newer versions of the jupyter suite will also fail on > > riscv64 because of the same reason, but we'll find out... > > We prefer you handle this inside your package. There are multiple options I > can think of: > * Add a "Architecture: !riscv64" stanza to the test (you don't get useful > logs) > * Add a "skippable" restriction and exit 77 on riscv64 instead of the > regular exit code if non zero (you get logs to examine) > * I assume the tests use a python testing framework, you could mark the > individual failing tests as skipped (you get to catch regressions)
OK, I'll do one of these then, thanks! Closing this report. > > Will I need to request unblocks for riscv64 for each of the other > > Jupyter packages separately if they also fail the autopkgtests on > > riscv64 once I have uploaded them? > > For every source package that isn't already in testing with autopkgtests > running, failing tests will block indeed. Currently only existing failures > that failed since the start are non RC issues. Failures on amd64 and arm64 > are already RC [1]. Regressions are RC too. That's what I figured; I didn't know how you wanted to handle this "failed since the start" case for this new package. Best wishes, Julian
