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

Lucas Kanashiro lucas.kanashiro at
Wed Apr 27 19:12:28 UTC 2022


On Wed, Apr 27, 2022 at 3:55 PM Bryce Harrington <
bryce.harrington at> wrote:

> 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
> packaged).
> 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
> it.

I liked the proposed approach Bryce. What I am not sure about is using the
existent 'packaging' tag, from the page you linked "The bug is likely to be
a packaging mistake", some of those bugs are not necessarily a packaging
mistake but a reminder to revisit an upstream bug or reconsider part of the
delta we carry.

Thanks for working on this tool!
Lucas Kanashiro.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ubuntu-server mailing list