1. 15 Oct, 2018 4 commits
  2. 14 Oct, 2018 1 commit
  3. 29 Sep, 2018 8 commits
    • Simon McVittie's avatar
      Merge branch 'pycodestyle' into 'master' · 300ece79
      Simon McVittie authored
      Fix new pycodestyle warnings
      See merge request !37
    • Simon McVittie's avatar
      Fix most pycodestyle warnings for invalid escape sequences · aacea218
      Simon McVittie authored
      Recent pycodestyle versions add warnings for escape sequences not known
      to the current Python version. These currently expand to themselves,
      but could mean something different in a future Python version.
      In simple cases, use raw strings r'...' for regular expressions,
      shell scripts, and other strings likely to contain backslashes that
      are intended to be passed through to another interpreter like the
      regular expression parser or the shell.
      In more complex cases where the string already contains backslashes
      (other than in regular expressions), I've continued to use non-raw
      strings and just doubled the offending backslashes.
      In the test code, I've systematically used r'' for all regular
      expressions (even when it doesn't make any difference), since that seems
      least likely to introduce mistakes later.
      Note that
          assertRegex(foo, 'new\nline and\ttab')
          assertRegex(foo, r'new\nline and\ttab')
      both assert that foo contains "new<U+000A>line and<U+0009>tab", where
      <U+xxxx> represents the given control character. In the first match,
      the regular expression contains a literal U+000A (newline/line feed)
      and a literal U+0009 (horizontal tab), which match themselves, whereas
      in the second match, the regular expression contains the sequences
      backslash, n (which matches a newline) and backslash, t (which matches
      a tab).
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@debian.org>
    • Simon McVittie's avatar
      tests/pycodestyle: Print all warnings before exiting unsuccessfully · c4ef4765
      Simon McVittie authored
      If a new pycodestyle version introduces new warnings, we presumably
      want to report on them in all libraries and scripts, but `set -e`
      means we bail out early on a failed command. This resulted in, for
      example, not inspecting runner/autopkgtest if autopkgtest-virt-qemu
      provokes warnings.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@debian.org>
    • Simon McVittie's avatar
      Ignore pycodestyle W504 "line break after binary operator" · fdf611d4
      Simon McVittie authored
      pycodestyle 2.4.0 warns whenever a line break occurs at a binary
      operator; the intention seems to be that projects suppress either
      W503 or W504, whichever one they prefer. Recent revisions of PEP 8
      recommend breaking long lines before binary operators:
          if (foo
              and bar
              and baz):
      but it seems autopkgtest consistently breaks after binary operators:
          if (foo and
              bar and
      so enforce that one for now.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@debian.org>
    • Simon McVittie's avatar
      Merge branch 'trivial-904979' into 'master' · 474d735b
      Simon McVittie authored
      Implement the 'superficial' restriction
      See merge request !34
    • Simon McVittie's avatar
    • Simon McVittie's avatar
      Implement superficial as a test restriction · 3c17c0c4
      Simon McVittie authored
      This feature was previously prototyped under the name 'trivial'.
      Superficial tests do not provide significant test coverage, so if they
      pass, that does not necessarily mean that the package under test
      is actually functional. If a superficial test fails, it will be
      treated like any other failing test, but if it succeeds, this is
      only a weak indication of success. Continuous integration systems
      should treat a package where all non-superficial tests are skipped as
      equivalent to a package where all tests are skipped.
      For example, debian/tests/build in packages like dbus, libinput and
      pango1.0 should be marked as superficial. For packages that have other
      tests (like dbus and pango1.0), this has no effect on migration to
      testing unless the non-superficial tests happen to be skipped. For
      packages where the only test is superficial (like libinput), marking
      the test as superficial removes the migration delay bonus on success
      (because the test doesn't actually confirm that the library works,
      so we have to rely on user testing to detect most regressions), while
      retaining the migration delay penalty on failure.
      Based on a patch from Rebecca N. Palmer.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@debian.org>
      Closes: #904979
    • Simon McVittie's avatar
  4. 28 Sep, 2018 1 commit
  5. 12 Sep, 2018 1 commit
  6. 30 Aug, 2018 1 commit
  7. 22 Aug, 2018 1 commit
  8. 19 Aug, 2018 1 commit
    • Martin Pitt's avatar
      doc: Clarify scope of tests · 90876a75
      Martin Pitt authored
      autopkgtests are in no way limited to testing programs. Generalize the
      requirement that tests must test the installed *packages*, not just
      Side issue in #906617.
  9. 16 Aug, 2018 2 commits
  10. 10 Aug, 2018 4 commits
  11. 08 Aug, 2018 5 commits
  12. 07 Aug, 2018 1 commit
  13. 06 Aug, 2018 2 commits
  14. 05 Aug, 2018 1 commit
    • Antonio Terceiro's avatar
      test_breaks_testbed: allow output on stderr · 6460dd80
      Antonio Terceiro authored
      If anything in the tests of the sample package emits anything on stderr,
      this make the test fail. Since the actual test relies on the exit code
      of specific commands, this does not affect the functionality of the
      The tested use case was running the LxcRunner tests against a lxc
      container created by debci. The Debian lxc template calls debootstrap
      with --variant-minbase, so apt-utils is not installed, and that causes a
      warning on stderr by apt.
  15. 04 Aug, 2018 5 commits
  16. 03 Aug, 2018 1 commit
    • Ian Jackson's avatar
      doc/README.package-tests.rst: document hint-testsuite-triggers · 4e7af521
      Ian Jackson authored
      There is currently no official way to influence which packages trigger
      a retest on ci.d.n.  However, there is a trick, involving an
      unrunnable test which exists only to get its Depends into
      Testsuite-Triggers.  This is used by the dgit packagae.
      In lieu of a better mechanism, this trick ought to be documented.
      Documenting it also means that future ci machinery can know what this
      strange test actually means.
      Closes: #905310
      Signed-off-by: Ian Jackson's avatarIan Jackson <ijackson@chiark.greenend.org.uk>
  17. 01 Aug, 2018 1 commit