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

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to postgresql-common in Ubuntu.
https://bugs.launchpad.net/bugs/1748161

Title:
  improve britney hints for postgres MREs

Status in britney:
  New
Status in postgresql-common package in Ubuntu:
  Fix Released
Status in postgresql-common source package in Trusty:
  Triaged
Status in postgresql-common source package in Xenial:
  Triaged

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/britney/+bug/1748161/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to