Bug#826090: mate-terminal broken after todays upgrade (debian testing)

[Santiago Vila]

On Thu, Jun 02, 2016 at 05:30:35PM +0200, John Paul Adrian Glaubitz wrote:
> On 06/02/2016 05:09 PM, Santiago Vila wrote:
> > The testing ditribution is supposed to be in an always releseable state.
> 
> That is correct. But this particular fact is something that is inevitable
> and extremely hard to sort out. Also, the always releasable state is
> more related to RC bugs, not to testing being able for immediate
> release.
> 
> More precisely, it should be called "always freezable state", not "always
> releasable state". The latter is currently not really possible with the
> tools have.

Actually, it is completely possible with the tools we already have.

If Package A in testing does not work together with package B in unstable
which is about to enter testing, we can avoid having package A and B
together in testing by submitting a serious bug against package B.

> > If something does not work in *testing*, then of course it is a bug,
> > and you don't have to blame the submitter for that.
> 
> Except that this particular problem can not be avoided.

There is nothing special about this problem. Packages which do not
work together in testing but are supposed to work together should not
propagate to testing together in the first place.

If they do not work together at other levels, we also have the good
old "Conflicts".

> > To avoid what you call "artifacts" happening in testing we have a
> > thing called "transitions" and that's also why we sometimes submit
> > serious bugs against packages or group of packages in unstable just to
> > avoid them entering testing when they are not ready for testing.
> 
> Those transitions happen in unstable, not in testing. MATE was
> completely installable in unstable, shortly after src:marco was
> marked as ACCEPT.
> 
> I'm not aware of any transition mechanism for testing. Please educate me.

Packages do not propagate to testing when they have RC bugs.

Therefore, everything you need for a package not to enter testing
is to submit a serious bug (even if that may seem artificial) against it.

Very often, this kind of artificial bugs are submitted as part of an
ongoing transition to avoid the mess to propagate to testing.

Lots of people do that in case of need, and nobody will tell you that
the bug is "artificial" or that you should not submit it because it is
not a real bug.

> > But apparently you people didn't do anything like that (or you didn't
> > do it right enough) and this time packages which do not work together
> > have entered testing at the same time.
> > 
> > Again, this is not supposed to happen in *testing*.
> 
> But it happens and is a non-issue for anyone who knows how testing
> and unstable work.

Sorry, if you keep mixing testing and unstable in the same bag, I'll continue
to think that it's you who don't know how testing is supposed to work.

Of course testing is in development, but we want it to be as stable
as possible, not just "another unstable".

> > For the record: As of today, none of the following source packages in
> > stretch may be built in stretch due to unmet build-dependencies:
> 
> We have never built packages in testing. All packages have "unstable"
> in the changelog. Uploading things directly into testing is possible
> during freeze only and only if there is absolutely no way around it.

Nobody talked about uploading things directly into testing.

I was just stating a fact: There are a bunch of MATE packages in
stretch which may not be built in stretch, because their
build-dependencies are not in stretch, or may not be met in stretch.

This is RC by any metric you may have.


For the mate-terminal package, for example, this is what happens:

  Build-Depends: libmate-desktop-dev (>= 1.14) but it is not going to be installed


A serious bug against mate-terminal would have prevented the mate-terminal
from the new MATE to enter testing before the rest of MATE.

Now it's too late, but that's not an excuse to tell people not to
report bugs.

Thanks.