Your message dated Fri, 24 Jul 2026 11:48:50 +0000
with message-id <[email protected]>
and subject line Bug#1142665: fixed in dgit 15.14
has caused the Debian Bug report #1142665,
regarding Perf problems with new autopkgtest especially on riscv64
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
1142665: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142665
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: debci

tl;dr:

  Please can you increase (double, say) the timeout for the srd:dgit
  autopkgtests on riscv64.


Problem

src:dgit has over 100 tests, organised by test-dependencies into about
about 30 stanzas.  This has generally been fine and is a mode of use
I anticipated when I designed autopkgtest.  A formal src:dgit test run
under autopkgtest takes under an hour on my amd64 laptop.

The large number of stanzas does mean that the test runner needs to
reset the testbed and install the test-dependencies dozens of times.
On some slow runners, this was being a problem.  I filed
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063533
about this (in February 2024).

To work around the problem with Debian's very slow riscv64 runners I
added `Architecture: !riscv64` to the least useful and most
long-running stanzas.  This made things reliable.

However, recently, autopkgtest was changed to always reset the testbed
and reinstall the test dependencies, for every test case:
  
https://tracker.debian.org/news/1775760/accepted-autopkgtest-60-source-into-unstable/

For src:dgit's DEP-8 tests, that represents about a 4x performance
regression.  Test runs that used to take 2-5h on riscv64 now usually
time out after ~8h.

Also, it has almost entirely negated the previous workaround I had for
riscv64.  I had focused on reducing the number of stanzas, since that
would reduce the total number of resets and reinstalls.

This problem doesn't just inconvenience the src:dgit maintainers and
users.  dgit lives at the top of a very large dependency stack.  Right
now it seems like the perl transition may get hung up on this problem.


Possible solutions

1. We could revert the change to autopkgtest.

  I think this would probably be controversial, despite this change
  effectively being a release critical regression for src:dgit.

  (TBH I am disappointed that this change was made despite the
  knowledge, provided in #1063533, that it would probably cause
  serious regressions for at least some use cases, and without any
  kind of coordination such as an MBF for packages with many test
  cases, a proper transition plan, etc.)

  More realistically it might be possible to put something in the test
  metadata.  "Features: ok-to-reuse-testbed-for-multiple-tests" or
  something.  Having the src:dgit test suite declare a new feature is
  an easy low-risk change which would be eminently backportable.

2. It would be possible to re-engineer the src:dgit test suite so that
  all the test cases which share a common set of test dependencies are
  represented in a single stanza in debian/tests/control.

  However, it's not clear that this would actually solve the problem
  because wouldn't want to backport such a change to stable branches.
  So at least some CI runs would probably still be afllicted.

  It would entail significant regression to reporting of failures.
  Right now when a test fails, you know which test case failed because
  that's captured in autopkgtest's structured output.  It's hard to
  make portmanteau test cases have good names in the autopkgtest data,
  and when they fail you'd have to find and eyeball the right bit of
  the output to find out which actual test(s) failed.

  Also, that would be quite an intrusive change.  Right now I am
  juggling an experimental branch and also trying to land an important
  bugfix in testing.  I think trying to do this test suite
  reorganisation at the same time is very risky.  I could do it later.
  But I think we need a short term fix.

3. We could have riscv64 runners which provide better (and more
  consistent) performance.

4. We could increase the timeout.  We'd still end up wasting computing
  resources but at least the tests would pass and not need to be
  repeated.

5. I could mark the vast majority of th cases tests !riscv64, leaving
  only a handful.  The dgit test suite is not designed with this in
  mind, but in practice it has I think never detected any
  arch-specific bugs so that's probably OK?

I think only options 1 (revert in autopkgtest), 4 (increased timeout)
and 5 (do almost no testing on riscv64) are technically feasible in
the short term.  I think the autopkgtest maintainers probably don't
want to revert.

So in the short term, I think the answer is an increased timeout.  I'm
hoping you (the debci team) can do that for me.


Thanks,
Ian.

-- 
Ian Jackson <[email protected]>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- End Message ---
--- Begin Message ---
Source: dgit
Source-Version: 15.14
Done: Ian Jackson <[email protected]>

We believe that the bug you reported is fixed in the latest version of
dgit, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ian Jackson <[email protected]> (supplier of updated dgit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Fri, 24 Jul 2026 10:48:24 +0100
Source: dgit
Architecture: source
Version: 15.14
Distribution: unstable
Urgency: medium
Maintainer: Debian tag2upload Delegates <[email protected]>
Changed-By: Ian Jackson <[email protected]>
Closes: 1142665
Changes:
 dgit (15.14) unstable; urgency=medium
 .
   * CI: More firmly insist on using testing, not sid
   * autopkgtests: Run only a very small handful of tests on riscv64
     to work around autopkgtest 4x perf regression.  Closes: #1142665.
Checksums-Sha1:
 2620b1d78944878af7c3ebbe87fe9f59d7940740 2533 dgit_15.14.dsc
 c2343edda59f2ec3beeaad1dd52e569aafc1c7a7 1064439 dgit_15.14.tar.gz
 8e0e8c748e058b0892c6c86cac8832f930e065fe 1366636 dgit_15.14.git.tar.xz
 20616c54980e0ee5cd8fe7f1b54572357995af0f 17526 dgit_15.14_source.buildinfo
Checksums-Sha256:
 ba7f26eb973b7ff0b091304227279b2030bd10ec5670829ea580b09b83f4175c 2533 
dgit_15.14.dsc
 7070244f6b5a142711d28b6c873438d2c87db4c6b2ad723c234bf9030d6cc48a 1064439 
dgit_15.14.tar.gz
 db06d6b3934458e7adb5cb968c1c788b2785b840c0915edad9637c5acb20acd5 1366636 
dgit_15.14.git.tar.xz
 435542b3dd6cc6edb3955211d2a1edb7eae0d7280f2dde1c5c608f58d68b8abc 17526 
dgit_15.14_source.buildinfo
Files:
 173d3c5dbdb186653540a604ae0be2a0 2533 devel optional dgit_15.14.dsc
 a0756467a352fe5b16ec36b837daaedf 1064439 devel optional dgit_15.14.tar.gz
 73febd295ed3ec65b6f0c73b6b98cc68 1366636 devel optional dgit_15.14.git.tar.xz
 e2bf747a9f1e1c868704129b7341ef87 17526 devel optional 
dgit_15.14_source.buildinfo
Git-Tag-Info: tag=c7c47b531d18e4b93dcfeea20144e9fc9678460b 
fp=41638114d132883b25a20ddd47515757d8002456
Git-Tag-Tagger: Ian Jackson <[email protected]>

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEN02M5NuW6cvUwJcqYG0ITkaDwHkFAmpjTIsACgkQYG0ITkaD
wHnD5hAAqUN9vsjYKeaJH6egHUrLdbhfZogBTuFbK+Bp61AmzsaM1gozuNQgJL4G
haH9x3kIiE8SPDARxSjn+huQVQOp2VHX9Fn3ndbaagttm/OLrPmQL4Gs8fNn3aAY
nX8kSlmJSsa94tgYi6Xt90tKCcJorxrQn6FIJQrAb0wto7zj1DOYgVihtRWsNfr3
Lgs535eITFxfHTfFgQ4UFTzgjWEUQQkCccdeeVxs3dpKkaxXqdy+MKo/aivOsnPs
doX7wlk2/FClRzY+sUXuouQQEfokZOKKjj9qNPvBF6tMUCVMiN97JBG4fGnQTigk
cR7MI60AvkFtEolWUMC5v9mzgxA+5ZRZWEbG8tD1dX82vO3Z1eTLcrSPSuKBqF/q
OxnkorqyqmiRb1zp8Lu8FOttm6GwNwNM9wGLuI9a5jY2d3kpAK7GBY2UnsWRh3/m
3ylt4R3DlC4fU0vHGjllZoX3Lq4D+7dGl5eahRxuSzjCGyoKaJtqJDctV5qwZrVu
VLH+tIPnh9FfLxzkhLb1lQ4JXib2Yn6KqI5gM4aP/u4PCB0OCyYGZfrRKQAEWoEn
vp+erm949ge4Epja6yT4QOwEVr9Ykmxbf/v95obMaHou+v2peA+zdOepwVL/f0Ju
VZKI9Rh00J5OMUOLgHCXcTOEjyRYteJGrs6SDz4D0Fspgbg6edI=
=bxrW
-----END PGP SIGNATURE-----

Attachment: pgp3UHtaKqRHm.pgp
Description: PGP signature


--- End Message ---

Reply via email to