improve britney hints for postgres MREs

Bug #1748161 reported by  Christian Ehrhardt  on 2018-02-08
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
britney
Undecided
Unassigned
postgresql-common (Ubuntu)
Undecided
Unassigned
Trusty
Undecided
Unassigned
Xenial
Undecided
Unassigned
Artful
Undecided
Unassigned

Bug Description

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

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

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.

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

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

affects: postgresql-9.5 (Ubuntu) → postgresql-common (Ubuntu)
Changed in postgresql-common (Ubuntu):
status: New → Fix Released
Changed in postgresql-common (Ubuntu Trusty):
status: New → Triaged
Changed in postgresql-common (Ubuntu Xenial):
status: New → Triaged

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

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 ...

s/MRE/MPs/

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.

Related MPs just all got merged.
Thanks!

Changed in postgresql-common (Ubuntu Artful):
status: New → Fix Released
Changed in postgresql-common (Ubuntu Xenial):
status: Triaged → Fix Released
Changed in postgresql-common (Ubuntu Trusty):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers