improve britney hints for postgres MREs

[Christian Ehrhardt ]

On every postgres MRE we mention some regular failing tests.
Those were mostly caused by changes in the environment and fixes were done for later Ubuntu releases but not SRUable.
We should not ask the release team to force them on every SRU but cover those where it is correct with badtest entries.

So this is about collecting this information and adapting hints for britney accordingly.

Due to changes from lxc -> lxd (documented by pitti and carried on since then)
- trusty
  - postgresql-9.3/armhf
- Xenial
  - postgresql-9.5/armhf
  - mimeo/armhf

FYI - there are also some long term always fail cases.
Often had just 1-2 good runs on old pgsql versions and hen never again - resolved in latter releases. Those packages are in universe only and are already covered by hints.
- Xenial
  - pgfincore, see [1]
  - orafce, see [2]
  - postgresql-plproxy, see [3]
  - pgpool2, since pgpool2/3.4.3-1 see [4] as an example

Some others are known flaky tests are there as well, but I don't want to overrid all those to keep their coverage.
E.g. dbconfig-common failed on artful due to mysql (but one can see in the log postgres is good which for this update is the important part).

But for those above that are due to the LXC/LXD change there is no reason to bump it on every MRE.
It won't change - so lets propose them unversioned to not need this over and over again.

[1]: http://autopkgtest.ubuntu.com/packages/pgfincore/xenial/amd64
[2]: http://autopkgtest.ubuntu.com/packages/orafce/xenial/amd64
[3]: http://autopkgtest.ubuntu.com/packages/postgresql-plproxy/xenial/amd64
[4]: http://autopkgtest.ubuntu.com/packages/pgpool2/xenial/amd64

[Christian Ehrhardt  (paelzer)]

Linked two MPs which - if merged - will eliminate the ususal suspects and leave the actual real cases for discussion on each MRE/SRU activity.

[Christian Ehrhardt  (paelzer)]

I'm not sure on the bug tasks, but the MPs will certainly go on the queue of the SRU Team where they are at the right place.

[Christian Ehrhardt  (paelzer)]

List of past MRE updates were to a different extend always the same discussions on test fails came up - to provide the reasonability to add these hints.
- pad.lv/1637236
- pad.lv/1664478
- pad.lv/1690730
- pad.lv/1713979
- pad.lv/1730661
- pad.lv/1747676

[Christian Ehrhardt  (paelzer)]

We abandoned the trusty change and reduced the xenial change to mimeo.
On the next MRE we want to bundle backporting
- https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-common.git/commit/?id=fc40fc34ce
- https://salsa.debian.org/postgresql/postgresql-common/commit/07ea2e63241c9806
in postgresql-common and upload it together with the actual MRE

[Christian Ehrhardt  (paelzer)]

Notes:
[12:29] <rbasak> cpaelzer: one note: when you do the next postgresql MRE, get the SRU reviewer to accept postgresql-common and want for binaries to be published before accepting the others
[12:29] <rbasak> Then the dep8 test will definitely run against the new one.
[12:30] <rbasak> (I don't think a versioned dependency relationship is needed here)
[12:30] <rbasak> s/want/wait/
[12:31] <pitti> that's not true
[12:31] <pitti> dependencies are satisfied from relelase/-updates as far as possible
[12:31] --> milardovich (~milardovi@190.193.40.124) has joined this channel.
[12:32] <pitti> you either need a versioned test dependency, or explicitly trigger the test to run against p-common in -proposed
[12:32] <rbasak> Oh.
[12:32] <pitti> (the latter appears better to me)
[12:32] <rbasak> OK we'll do an explicit trigger
[12:32] <rbasak> Thanks
[12:32] <pitti> i. e. see it fail, re-trigger armhf tests against p-common in -proposed, that should succeed and also validate the p-common SRU
[12:33] <pitti> although bumping the test dep in postgresql's d/tests/comtrol isn't wrong
[12:33] <cpaelzer> just as I did last week with some other migrations
[12:33] <rbasak> I generally shy away from bumping versioned deps to reflect bug fixes on the other side
[12:33] <pitti> (except the typoed file name, of course - tpying is hrad!)
[12:34] <rbasak> Seems like a recipe to madness
[12:34] <pitti> yeah, and breaks the clean backports, too
[12:34] <pitti> so I think manual trigger for that one round is just fine
[12:34] <rbasak> Yep

[Christian Ehrhardt  (paelzer)]

mimeo was already done, the two regular armhf fails are part of an MP now that we have a "normal" SRU update again.
Linking MRE to this bug ...

[Christian Ehrhardt  (paelzer)]

s/MRE/MPs/

[Christian Ehrhardt  (paelzer)]

This is a tradeoff of effort vs gain - and in the past discussions were back and forth on trying to fix pgsql-common to make the lxd based tests work OR to hint them on britney.
While in a perfect world we'd prefer the former for now I proposed the latter.
Armhf is not a major target for postgresql and there never was an issue on armhf exclusive so far and on newer release this is fixed.
Also this isn't backportable that well to Trusty, and to do this only for Xenial feels wrong.
Really lets mask the known issues and be good.

Only if denied I'd (unwillingly) reconsider this, but really only then.

[Christian Ehrhardt  (paelzer)]

Related MPs just all got merged.
Thanks!