group.of.nepali.translators team mailing list archive

[Rafael David Tinoco <rafaeldtinoco@xxxxxxxxxxxxxx>]

> TODO: marking as a duplicate of: LP: #1736882
TODO: marking as a duplicate of: LP: #1836882

** This bug has been marked a duplicate of bug 1836882
   autopkgtest due to other packages changing

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1836929

Title:
  chrony has migration regressions from autopkgtests (disco/eoan)

Status in chrony package in Ubuntu:
  Fix Released
Status in chrony source package in Xenial:
  Won't Fix
Status in chrony source package in Bionic:
  Won't Fix
Status in chrony source package in Cosmic:
  Won't Fix
Status in chrony source package in Disco:
  Triaged
Status in chrony source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * Recent changes have caused the chrony autopkgtests to fail.
     In this case upstream of chrony and the clk tests changed, which need 
     to be back under control to match what works reliably for Disco.

   * Later versions have this fixed, backport the changes to fix it in Disco
     as well

  [Test Case]

   * Let the autopkgtests run (which is part of the proposed migration
     anyway)
     Sniffs already show them completing:
     https://bileto.ubuntu.com/excuses/3759/disco.html

  [Regression Potential]

   * There is no functional change, only the self-tests as well the
     autopkgtest execution are changed.
     The one source for a regression could be that the rebuild picks
     something up that triggers a behavior change. But the PPA builds have
     not shown something (at least not something obvious)

  [Other Info]

   * This is one of the cases where the actual package as used by the user
     has no bug. I'm unsure how to proceed. Do we want to push it just to
     disco-proposed but keep it there (to avoid downloads for "nothing")?
     I know rbasak wanted to discuss that in the SRU team for the even worse
     https://bugs.launchpad.net/cloud-archive/+bug/1829823/comments/14
     To some extend this come under the same banner.
   * If this is denied from SRU for this reason I'd ask to add a force-
     badtest as a replacement to unblock proposed migration.

  ---

  Checking last eoan merge I realized that some tests were failing for
  chrony:

  https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/369588/comments/967625

  But eoan ran autopkgtests okay when the trigger was
  chrony/3.5-2ubuntu2 (this last merge):

  http://autopkgtest.ubuntu.com/packages/chrony/eoan/amd64

  Despite having failed for the previous 12 times (eoan).

  Now, for the first time, we have the same failure for disco:

  http://autopkgtest.ubuntu.com/packages/chrony/disco/amd64

  http://bit.ly/2LpMx4G

  """
  make: Leaving directory '/tmp/autopkgtest.pBHSAl/build.WCD/src/test/simulation/clknetsim'
  ...
  110-chronyc                   .................... PASS
  111-knownclient               xxxxxxxxxxxxxxxxxxxx FAIL
  112-port                      xxxxxxxxxxxxxxxxxxxx FAIL
  121-orphan                    .................... PASS
  ...
  SUMMARY:
    TOTAL  50
    PASSED 48
    FAILED 2    (111-knownclient 112-port) (255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 265)
  """

  And I'm able to reproduce locally:

  """
  (c)inaddy@iproute2verification:~/work/sources/ubuntu/chrony/test/simulation$ ./111-knownclient
  Testing reply to client configured as server:
    network with 1*1 servers and 1 clients:
      non-default settings:
        client_conf=acquisitionport 123
        server_conf=server 192.168.123.2 noselect acquisitionport 123
      starting node 1: OK
      starting node 2: OK
      running simulation: OK
      checking chronyd exit:
        node 1: OK
        node 2: OK
      checking source selection:
        node 2: OK
      checking port numbers in packet log:
        node 1: BAD
        node 2: BAD
  FAIL

  AND

  (c)inaddy@iproute2verification:~/work/sources/ubuntu/chrony/test/simulation$ ./112-port
  Testing port and acquisitionport directives:
    network with 1*1 servers and 1 clients:
      non-default settings:
      starting node 1: OK
      starting node 2: OK
      running simulation: OK
      checking chronyd exit:
        node 1: OK
        node 2: OK
      checking source selection:
        node 2: OK
      checking mean/min incoming/outgoing packet interval:
        node 1: 2.74e+02 2.74e+02 6.40e+01 6.40e+01 OK
        node 2: 2.74e+02 2.74e+02 6.40e+01 6.40e+01 OK
      checking clock sync time, max/rms time/freq error:
        node 2: 132 9.29e-05 1.21e-06 5.77e-05 1.01e-07 OK
      checking port numbers in packet log:
        node 1: BAD
        node 2: BAD
    network with 1*1 servers and 1 clients:
      non-default settings:
        client_conf=acquisitionport 123
      starting node 1: OK
      starting node 2: OK
      running simulation: OK
      checking chronyd exit:
        node 1: OK
        node 2: OK
      checking port numbers in packet log:
        node 1: BAD
        node 2: BAD
  FAIL
  """

  When doing verification for an iproute2 bug (LP: #1831775) we faced
  the 1st failure in autopkgtests for chrony in disco (at least from the
  ones I can check from autopkgtests.ubuntu.com).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1836929/+subscriptions