Hi,
tl;dr: we need to cook up a similar patch as
bd375fdd85b4e00b89fb087760369bb6f3df0a20 for the migration phase of britney.
We recently experienced this problem in Debian too.
Traceback (most recent call last):
File "/srv/
release.debian.org/britney/code/b2/britney.py", line 1586,
in <module>
Britney().main()
File "/srv/
release.debian.org/britney/code/b2/britney.py", line 1573,
in main
self.upgrade_testing()
File "/srv/
release.debian.org/britney/code/b2/britney.py", line 1244,
in upgrade_testing
self.run_auto_hinter()
File "/srv/
release.debian.org/britney/code/b2/britney.py", line 1518,
in run_auto_hinter
for lst in self.get_auto_hinter_hints(self.upgrade_me):
File "/srv/
release.debian.org/britney/code/b2/britney.py", line 1482,
in get_auto_hinter_hints
hint = find_related(e, set(), True)
File "/srv/
release.debian.org/britney/code/b2/britney.py", line 1471,
in find_related
if not find_related(p, hint):
File "/srv/
release.debian.org/britney/code/b2/britney.py", line 1471,
in find_related
if not find_related(p, hint):
File "/srv/
release.debian.org/britney/code/b2/britney.py", line 1471,
in find_related
if not find_related(p, hint):
[Previous line repeated 989 more times]
File "/srv/
release.debian.org/britney/code/b2/britney.py", line 1465,
in find_related
hint.add(excuse.item)
File
"/srv/
release.debian.org/britney/code/b2/britney2/migrationitem.py",
line 79, in __hash__
if not self.version:
RecursionError: maximum recursion depth exceeded
We discussed it on IRC and Sebastian worked around it...
[2022-08-28 UTC+2]
[16:20:20] <Sebastinas> elbrus: With the blocks on nginx and
openimageio/opencolorio removed, britney still crashes
[16:30:11] <Sebastinas> s/nginx and//g
[20:34:39] <elbrus> Sebastinas: so you added hints to "unbreak" britney?
[20:34:48] <Sebastinas> yes
[20:35:09] <elbrus> we should save the current state of the archive for
britneys test suite
[20:35:22] <elbrus> but I forgot how that worked
[20:35:55] -*- elbrus will try to figure it out, hopefully in time
[20:36:55] <Sebastinas> elbrus: The circular dependency of
openimageio/opencolorio triggers an endless recursion in the auto-hinter
[20:37:31] <elbrus> aha, now that's something that sounds like an
actionaly bug report for britney
[20:37:57] <elbrus> if we can reproduce the failure in a test
Thankfully Niels joined the discussion as he experienced the issue
before in the policy phase of britney:
[20:38:12] <nthykier> I am surprised, I thought the auto-hinter had
infinite-recursion detection already
[20:38:48] <elbrus> nthykier: if it's not in a test, it can be broken ;)
[20:39:33] <elbrus> I think I've seen these kind of errors a couple of times
[20:39:41] <elbrus> not so much in Debian
[20:48:20] <Sebastinas>
https://bpa.st/YSQA
[20:56:05] <nthykier> not sure that is infinite to be honest
[20:56:49] <nthykier> the other solver had to be rewritten to be
iterative because it would stack overflow (because some clusters
involved more then 1000 packages in a grouping)
[20:57:51] <nthykier> guess that time has come for the legay auto-hinter
as well now
[21:00:47] <nthykier> (the net effect is the same - it is just more
whether you will find a logical bug in the code or the code is "corect"
and we just surpassed the limit )
[21:00:53] <nthykier> correct*
[21:01:56] <elbrus> nthykier: thanks for the information
[21:03:42] <elbrus> nthykier: but how does making a solver iterative
prevent recursion limits (it sounds like it's normally the cause of
recursion)
[21:09:36] <nthykier> elbrus: the iterative solution replaces the
recursion (call stack) with a for-loop an a regular stack (python list).
The latter "only" limited by the amount of memory you have, where the
former is much more limited
[21:09:52] <nthykier> (s/for-loop/loop/)
[21:11:14] <elbrus> nthykier: do you happen to have a commit ID that was
involved in that rewrite (to get inpiration from if I need it)
[21:11:38] <nthykier> bd375fdd85b4e00b89fb087760369bb6f3df0a20
[21:12:40] <elbrus> thanks
[21:13:11] <elbrus> 5 years ago....
Paul