Activity log for bug #1836929

Date Who What changed Old value New value Message
2019-07-17 15:55:06 Rafael David Tinoco bug added bug
2019-07-17 15:58:40 Rafael David Tinoco description 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 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).
2019-07-17 15:58:44 Rafael David Tinoco chrony (Ubuntu): status New Confirmed
2019-07-17 15:58:53 Rafael David Tinoco nominated for series Ubuntu Eoan
2019-07-17 15:58:53 Rafael David Tinoco bug task added chrony (Ubuntu Eoan)
2019-07-17 15:58:53 Rafael David Tinoco nominated for series Ubuntu Disco
2019-07-17 15:58:53 Rafael David Tinoco bug task added chrony (Ubuntu Disco)
2019-07-17 15:58:59 Rafael David Tinoco chrony (Ubuntu Disco): status New Confirmed
2019-07-17 15:59:00 Rafael David Tinoco chrony (Ubuntu Disco): importance Undecided Medium
2019-07-17 15:59:02 Rafael David Tinoco chrony (Ubuntu Eoan): importance Undecided Medium
2019-07-17 15:59:03 Rafael David Tinoco chrony (Ubuntu Disco): assignee Rafael David Tinoco (rafaeldtinoco)
2019-07-17 15:59:05 Rafael David Tinoco chrony (Ubuntu Eoan): assignee Rafael David Tinoco (rafaeldtinoco)
2019-07-17 17:38:27 Rafael David Tinoco chrony (Ubuntu Disco): status Confirmed Won't Fix
2019-07-17 17:38:34 Rafael David Tinoco chrony (Ubuntu Eoan): status Confirmed In Progress
2019-07-17 18:01:47 Rafael David Tinoco chrony (Ubuntu Eoan): status In Progress Fix Released
2019-07-17 18:19:48 Rafael David Tinoco nominated for series Ubuntu Bionic
2019-07-17 18:19:48 Rafael David Tinoco bug task added chrony (Ubuntu Bionic)
2019-07-17 18:19:48 Rafael David Tinoco nominated for series Ubuntu Cosmic
2019-07-17 18:19:48 Rafael David Tinoco bug task added chrony (Ubuntu Cosmic)
2019-07-17 18:19:48 Rafael David Tinoco nominated for series Ubuntu Xenial
2019-07-17 18:19:48 Rafael David Tinoco bug task added chrony (Ubuntu Xenial)
2019-07-17 18:19:56 Rafael David Tinoco chrony (Ubuntu Cosmic): status New Won't Fix
2019-07-17 18:19:58 Rafael David Tinoco chrony (Ubuntu Bionic): status New Won't Fix
2019-07-17 18:20:00 Rafael David Tinoco chrony (Ubuntu Xenial): status New Won't Fix
2019-07-17 18:20:02 Rafael David Tinoco chrony (Ubuntu Cosmic): importance Undecided Medium
2019-07-17 18:20:04 Rafael David Tinoco chrony (Ubuntu Bionic): importance Undecided Medium
2019-07-17 18:20:06 Rafael David Tinoco chrony (Ubuntu Xenial): importance Undecided Medium
2019-07-17 18:20:10 Rafael David Tinoco chrony (Ubuntu Disco): assignee Rafael David Tinoco (rafaeldtinoco)
2019-07-17 18:22:14 Rafael David Tinoco bug added subscriber Christian Ehrhardt 
2019-07-17 18:22:22 Rafael David Tinoco bug added subscriber Canonical Server Team
2019-07-17 18:38:39 Launchpad Janitor branch linked lp:~rafaeldtinoco/britney/hints-ubuntu
2019-07-18 05:49:16 Christian Ehrhardt  chrony (Ubuntu Eoan): assignee Rafael David Tinoco (rafaeldtinoco)
2019-07-18 05:49:20 Christian Ehrhardt  chrony (Ubuntu Disco): status Won't Fix Triaged
2019-07-18 09:41:20 Christian Ehrhardt  description 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). [Impact] * Recent changes have caused the chrony autopkgtests to fail. Unfortunately it isn't known exactly what caused them, but obviously nothing that would have gated on chrony tests. Rafael still wants to take a look for the root cause in bug 1832050 but for now we need to resolve this in Disco which is affected. * 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).
2019-07-18 09:42:40 Christian Ehrhardt  description [Impact] * Recent changes have caused the chrony autopkgtests to fail. Unfortunately it isn't known exactly what caused them, but obviously nothing that would have gated on chrony tests. Rafael still wants to take a look for the root cause in bug 1832050 but for now we need to resolve this in Disco which is affected. * 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). [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).
2019-07-18 09:45:08 Christian Ehrhardt  merge proposal linked https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/370292
2019-07-18 13:05:00 Rafael David Tinoco marked as duplicate 1836882
2019-07-18 13:10:27 Christian Ehrhardt  removed duplicate marker 1836882
2019-07-18 13:15:04 Rafael David Tinoco chrony (Ubuntu Disco): status Triaged In Progress
2019-08-01 13:36:17 Rafael David Tinoco chrony (Ubuntu Disco): status In Progress Fix Released
2019-08-02 07:11:56 Timo Aaltonen chrony (Ubuntu Disco): status Fix Released In Progress
2019-08-02 07:16:18 Timo Aaltonen chrony (Ubuntu Disco): status In Progress Fix Committed
2019-08-02 07:16:20 Timo Aaltonen bug added subscriber Ubuntu Stable Release Updates Team
2019-08-02 07:16:22 Timo Aaltonen bug added subscriber SRU Verification
2019-08-02 07:16:25 Timo Aaltonen tags verification-needed verification-needed-disco
2019-08-02 09:41:02 Christian Ehrhardt  tags verification-needed verification-needed-disco verification-done verification-done-disco
2019-11-26 23:25:31 Chris Halse Rogers tags verification-done verification-done-disco block-proposed-disco verification-done verification-done-disco
2020-07-02 19:53:30 Steve Langasek chrony (Ubuntu Disco): status Fix Committed Won't Fix