Triage and Migration report - Wed Feb 12, 2020

[Rafael David Tinoco]

Okay,

Do we have a map on components being kept for i386 and their
dependencies? I ask you this because of the following situation: I
could mark the pacemaker/all/i386 as a badtest. It would solve the
migration problem BUT then, when investigating, I see that:

pacemaker-resource-agents package (present in amd64 and i386 repos) depends on:

(c)rafaeldtinoco at clusterx32:~$ apt-cache policy resource-agents
resource-agents:amd64:
  Installed: (none)
  Candidate: 1:4.4.0-1ubuntu1
  Version table:
     1:4.4.0-1ubuntu1 500
        500 http://br.archive.ubuntu.com/ubuntu focal/main amd64 Packages

which is currently unavailable for i386. My doubt is: should we ask
"resource-agents" to be included back in i386 then ? OR should we try
to get rid of pacemaker in i386 ? I'm not entirely sure why it is
being kept while resource-agents was removed... that is why I ask.

Even having the big list of things we want to keep for i386
environments, there are dependencies kept (or not) by a decision. Is
this placed somewhere ? Or we should concentrate all of those in you ?

The original rdepends for resource-agents is:

rafaeldtinoco at workstation:~$ apt-cache rdepends resource-agents
resource-agents
Reverse Depends:
  resource-agents-dbgsym
  pacemaker-resource-agents
  ceph-resource-agents
  resource-agents-paf
  heartbeat
  ceph-resource-agents

Should we open a bug and point you to for each of "these cases" where
we can't know if we should go ahead in removal or go backwards in
dependencies ?

Thanks Steve!

On Thu, Feb 13, 2020 at 10:17 AM Rafael David Tinoco
<rafaeldtinoco at ubuntu.com> wrote:
>
> > > Yep, pacemaker has some issues for i386 as well. Migration is blocked
> > > because of that. I also assumed we didn't have to do anything here.
> >
> > The existing test failures for packages in the release pocket have all been
> > hinted away so that they don't impact velocity, but it's the responsibility
> > of uploaders to address the failing autopkgtests as part of the new upload,
> > whether that's analyzing the failures and recommending to the release team
> > that the failures be permanently ignored, or fix the tests for
> > cross-testing.
>
> Definitely! We do that, and it's a "general" rule among us to check migrations
> every morning, as an example of what you said. My thought was that we had
> something else on-going for the i386-only autopkgtests. If not, I'll just go
> ahead and hint it for i386 based on latest failures.
>
> Thank you!