autopkgtest due to other packages changing

Bug #1836882 reported by Christian Ehrhardt  on 2019-07-17
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
chrony (Ubuntu)
Undecided
Unassigned
Disco
Medium
Unassigned

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

---

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.

Related branches

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

Both pass now in local autopkgtets as expected

Launchpad Janitor (janitor) wrote :
Download full text (4.6 KiB)

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

Read more...

Changed in chrony (Ubuntu):
status: New → Fix Released

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

Changed in chrony (Ubuntu Disco):
status: New → Triaged
summary: - autopkgtest due to other packages chaning
+ autopkgtest due to other packages changing

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.

description: updated
Changed in chrony (Ubuntu Disco):
importance: Undecided → Medium

MP acked, Uploaded to disco-unapproved

Changed in chrony (Ubuntu Disco):
status: Triaged → In Progress
Changed in chrony (Ubuntu Disco):
status: In Progress → Fix Released
Timo Aaltonen (tjaalton) on 2019-08-02
Changed in chrony (Ubuntu Disco):
status: Fix Released → In Progress

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.

Changed in chrony (Ubuntu Disco):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-disco
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers