Your message dated Mon, 29 Jul 2024 08:04:13 +0100
with message-id <zqc-7spmdrsb1...@d-and-j.net>
and subject line Re: Bug#1077314: unblock: pytest-jupyter/0.9.1-2
has caused the Debian Bug report #1077314,
regarding unblock: pytest-jupyter/0.9.1-2
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1077314: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077314
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian....@packages.debian.org
Usertags: unblock

Please unblock package pytest-jupyter

[ Reason ]
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...

[ Impact ]
The newer versions of the jupyter suite all depend on pytest-jupyter
for their autopkgtests.

[ Tests ]
N/A

[ Risks ]
The Jupyter suite may not work on riscv64.

[ Checklist ]
N/A

[ Other info ]
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?

Thanks!

unblock pytest-jupyter/0.9.1-2
# Perhaps instead:
# unblock pytest-jupyter/0.9.1-2/riscv64

--- End Message ---
--- Begin Message ---
Oops, forgot to close

On Mon, Jul 29, 2024 at 08:03:44AM +0100, Julian Gilbey wrote:
> 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


   Julian

--- End Message ---

Reply via email to