Monday bug triage report (2022-04-22 -> 2022-04-24)

Bryce Harrington bryce.harrington at
Wed Apr 27 18:55:03 UTC 2022

On Mon, Apr 25, 2022 at 12:04:47PM -0300, Lucas Kanashiro wrote:
> Bugs last updated between 2022-04-22 (Friday) and 2022-04-24 (Sunday)
> inclusive
> Date range identified as: "Monday triage"
> Found 10 bugs
> The number of bugs was lower than I was expecting because of the Jammy
> release. Comments below:
> # - (New)            [openssh]           - User
> process fault: interruption code 0011 ilc:3 on SSH cli…
> This is a bug in a virtualized environment in s390x, I was not able to
> reproduce it yet. It'd be helpful if Christian could take a quick look to
> see if it rings a bell to him.
> # - +(Triaged)       [multipath-tools]   - Consider
> dropping d/p/kpartx-Improve-finding-loopback-devic…
> This bug is in our backlog and has not been touched in 60 days. I think we
> should consider this when merging multipath-tool during the KK cycle.
> Bryce, is there any way to get this linked to the merge bug that your
> tooling will create?

There's not, however this request has come up a couple times before, so
rule of three suggests we do need a way to track these.

Previously I've just stuck them in my personal todo list to mention in
bug reports, and I can do that in this case too.  (I'm probably going to
take the merge for multipath-tools this cycle anyway.)

But to solve this more generally:

The tooling already knows how to look for bugs with tags, so what if
during the regular triage process we tag such bugs with an agreed on
tag.  Then when the merge board is generated, the tools would query any
such tagged bugs still open for the given package and itemize them in
the bug report description.

Looking at, there is already a
'packaging' bug tag, defined as a packaging related problem (as opposed
to 'needs-packaging' which marks packaging of software not yet

Presumably any bug marked 'packaging' against one of our packages
probably *should* be considered during merge anyway, so if we used it
for this purpose it doesn't seem like we'd be misusing or overloading


More information about the ubuntu-server mailing list