autopkgtest due to other packages changing

[Christian Ehrhardt ]

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

---

Somewhat expected (but we wanted to see it for real) is an autopkgtest in Chrony that fails since some past update to iproute (or earlier).

Example:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/c/chrony/20190717_081612_33487@/log.gz

The error is:
time-sources-from-dhcp-servers FAIL stderr: md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v4-dummy0.conf: No such file or directory

It is uncritical for the test, but it triggers on stderr being present.

[Christian Ehrhardt  (paelzer)]

Since otherwise we don't need stderr-tracking for this test we can allow it and should be good.

[Christian Ehrhardt  (paelzer)]

Both pass now in local autopkgtets as expected

[Launchpad Janitor (janitor)]

This bug was fixed in the package chrony - 3.5-2ubuntu2

---------------
chrony (3.5-2ubuntu2) eoan; urgency=medium

  * d/t/control: allow stderr for recent changes in resolved/iproute
    (LP: #1836882)

chrony (3.5-2ubuntu1) eoan; urgency=medium

  * Merge with Debian experimental (LP: #1835046). Remaining changes:
    - d/chrony.conf: use ubuntu ntp pool and server (LP 1744664 1754358)
    - Set -x as default if unable to set time (e.g. in containers) (LP 1589780)
      Chrony is a single service which acts as both NTP client (i.e. syncing the
      local clock) and NTP server (i.e. providing NTP services to the network),
      and that is both desired and expected in the vast majority of cases.
      But in containers syncing the local clock is usually impossible, but this
      shall not break the providing of NTP services to the network.
      To some extent this makes chrony's default config more similar to 'ntpd',
      which complained in syslog but still provided NTP server service in those
      cases.
      + debian/chrony.service: allow the service to run without CAP_SYS_TIME
      + debian/control: add new dependency libcap2-bin for capsh (usually
        installed anyway, but make them explicit to be sure).
      + debian/chrony.default: new option SYNC_IN_CONTAINER to not fall back
        (Default off) [fixed a minor typo in the comment in this update]
      + debian/chronyd-starter.sh: wrapper to handle special cases in containers
        and if CAP_SYS_TIME is missing. Effectively allows to run NTP server in
        containers on a default installation and avoid failing to sync time (or
        if allowed to sync, avoid multiple containers to fight over it by
        accident).
      + debian/install: make chrony-starter.sh available on install.
      + debian/docs, debian/README.container: provide documentation about the
        handling of this case.
   * Dropped changes (accepted in Debian now):
    - d/postrm: re-establish systemd-timesyncd on removal (LP 1764357)
    - d/postrm: respect policy-rc.d when restoring systemd-timesyncd
      (LP 1771994)

chrony (3.5-2) unstable; urgency=medium

  * Merge branch “experimental” into “master”.

  * debian/chrony.dhcp:
    - Fix shellcheck warnings. Patch imported from Fedora.

  * debian/chrony-helper:
    - Fix shellcheck warnings. Patch imported from Fedora.

  * debian/clean:
    - Drop obsolete entries.

  * debian/copyright:
    - Update copyright years.
    - Update copyright holder for the configure script.

  * debian/patches/*:
    - Add update_processing_of_packet_log.patch. This fixes a regression in
    the simulation tests exhibited by the recent clknetsim changes.
    (Closes: #931181)

  * debian/rules:
    - Use dh_missing --fail-missing.

  * debian/tests/upstream-simulation-test-suite:
    - Use a known good clknetsim commit. This should prevent regressions from
    on-going “clknetsim” development.

  * debian/usr.sbin.chronyd:
    - Grant access rights only to the ntp_signd socket. (Closes: #928170)

  [ Christian Ehrhardt ]
  * debian/postrm:
    - Re-establish systemd-timesyncd on removal. (MR: !1)

chrony (3.5-1) experimental; urgency=medium

  * Impor...

[Christian Ehrhardt  (paelzer)]

It seems this now also affects Disco, some other change (that was not triggering chrony tests) got in that now makes it break.

[Christian Ehrhardt  (paelzer)]

In a bunch of retries I have not always seen this on Disco, but since we are going to propose an SRU just for testing (for bug 1836929) anyway we can as well make sure this doesn't stab us in the back by adding it right away.

[Christian Ehrhardt  (paelzer)]

MP for disco [1] is up and ready for review

[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/370292

[Christian Ehrhardt  (paelzer)]

MP acked, Uploaded to disco-unapproved

[Timo Aaltonen (tjaalton)]

Hello Christian, or anyone else affected,

Accepted chrony into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/chrony/3.4-1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

The fix for this bug has been awaiting testing feedback in the -proposed repository for disco for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository.

[Christian Ehrhardt  (paelzer)]

Thanks Brian,
I'm unsure how this was lost - will clarify it.

[Christian Ehrhardt  (paelzer)]

Ah we had two bugs and I only updated one back then - my mistake.
The other bug is bug 1836929

After double checking the build https://launchpad.net/ubuntu/+source/chrony/3.4-1ubuntu1.1 and the tests since then http://autopkgtest.ubuntu.com/packages/chrony/disco/amd64 it really is ok and should be verification-done.