On Sat, Oct 26, 2019 at 10:39:47PM +0200, José Luis Blanco-Claraco wrote:
> However, I want to point out that we don't need to wait for
> mrpt-2.0.0, since the current version in unstable (1.5.8) already
> fixes this wxwidgets3.0-gtk3 bug.
> As you said, the problem now is the build issue in mipsel...
> I wrote an email to ftpmasters 12 days ago requesting the deletion of
> mrpt-1.x.x for mipsel, so we could go on quickly ago, but had no
> response yet.
It would need the mipsel build deleting from testing, which is the
domain of the release team, not ftpmaster. I actually suggested doing
this to the release team on October 18th, but they preferred letting the
AUTORM kick in.
The other option would have been to request a "giveback" - i.e. ask
the mipsel buildd to try again. I tried to trigger one via the new
self-service giveback mechanism, but my client certificate has expired
and firefox has dropped the feature which used to allow creating one
easily. Then the auto-opencv transition started before I got around
to creating a new client certificate the hard way.
> Perhaps a patch in debian/control to specify that we want mrpt-1.5.8
> to get built on all archs except mipsel?
That wouldn't help - there's already a mipsel build in testing so
the testing migration will decide not to update if there's no
mipsel build for the new version. Hence my attempt to get the
release team to manually remove the mipsel build from testing.
On Sat, Oct 26, 2019 at 10:46:19PM +0200, José Luis Blanco-Claraco wrote:
> Ok, sorry, forgot my last message, you already mentioned the new problem:
>
> > But now that missing mipsel build can't be addressed without
> > also updating mrpt for auto-opencv because it currently FTBFS in
> > unstable.
>
> It's a shame, but I think that perhaps I'll just leave mrpt to be
> removed from testing.
I think it's pretty much unavoidable at this point. But there's
plenty of time before bullseye for it to return.
> Anyway, mrpt-2 comes with many different
> packages so (if I recall it right...) the procedure would be similar,
> it will have to go through the "New queue" (sigh).
An existing source package gaining new binary packages ("binary NEW") is
usually processed more quickly (because it doesn't need a full licensing
review - it's mostly an "is this actually sensible" check).
If something being in binary NEW is blocking progress on a transition
you can usually get it processed sooner by asking nicely in #debian-ftp
and explaining succinctly what the reason is. I did that for openbabel
and limesuite which were in binary NEW and holding up uploads for the
wxwidgets3.0-gtk transition.
> Right now, addressing all the opencv4 changes in the mrpt-1.x branch
> would take me too much time, which will be better invested in going
> for the 2.0.0 version.
Yes, that sounds sensible.
Cheers,
Olly
