shutil.rmtree() fails when used in Fedora (rpm) "mock" environment

[c***@posteo.jp]

Hello,
I am upstream maintainer of "Back In Time" [1] investigating an issue a
distro maintainer from Fedora reported [2] to me.

On one hand Fedora seems to use a tool called "mock" to build packages
in a chroot environment.
On the other hand the test suite of "Back In Time" does read and write
to the real file system.
One test fails because a temporary directory is cleaned up using
shutil.rmtree(). Please see the output below.

I am not familiar with Fedora and "mock". So I am not able to reproduce
this on my own.
It seems the Fedora maintainer also has no clue how to solve it or why
it happens.

Can you please have a look (especially at the line "assert func is
os.lstat").
Maybe you have an idea what is the intention behind this error raised by
an "assert" statement inside "shutil.rmtree()".

Thanks in advance,
Christian Buhtz

[1] -- <https://github.com/bit-team/backintime>
[2] -- <https://github.com/bit-team/backintime/issues/1911>

__________________________ General.test_ctor_defaults
__________________________
self = <test.test_uniquenessset.General testMethod=test_ctor_defaults>
def test_ctor_defaults(self):
"""Default values in constructor."""
test/test_uniquenessset.py:47:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib64/python3.13/tempfile.py:946: in __exit__
self.cleanup()
/usr/lib64/python3.13/tempfile.py:950: in cleanup
self._rmtree(self.name, ignore_errors=self._ignore_cleanup_errors)
/usr/lib64/python3.13/tempfile.py:930: in _rmtree
_shutil.rmtree(name, onexc=onexc)
/usr/lib64/python3.13/shutil.py:763: in rmtree
_rmtree_safe_fd(stack, onexc)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
stack = []
onexc = <function TemporaryDirectory._rmtree.<locals>.onexc at
0xffffb39bc860>
def _rmtree_safe_fd(stack, onexc):
# Each stack item has four elements:
# * func: The first operation to perform: os.lstat, os.close or
os.rmdir.
# Walking a directory starts with an os.lstat() to detect
symlinks; in
# this case, func is updated before subsequent operations and
passed to
# onexc() if an error occurs.
# * dirfd: Open file descriptor, or None if we're processing the
top-level
# directory given to rmtree() and the user didn't supply
dir_fd.
# * path: Path of file to operate upon. This is passed to
onexc() if an
# error occurs.
# * orig_entry: os.DirEntry, or None if we're processing the
top-level
# directory given to rmtree(). We used the cached stat() of
the entry to
# save a call to os.lstat() when walking subdirectories.
func, dirfd, path, orig_entry = stack.pop()
name = path if orig_entry is None else orig_entry.name
try:
if func is os.close:
os.close(dirfd)
return
if func is os.rmdir:
os.rmdir(name, dir_fd=dirfd)
return

# Note: To guard against symlink races, we use the standard
# lstat()/open()/fstat() trick.

assert func is os.lstat

E AssertionError
/usr/lib64/python3.13/shutil.py:663: AssertionError

[Stefan Ram]

Post by c***@posteo.jp
Maybe you have an idea what is the intention behind this error raised by
an "assert" statement inside "shutil.rmtree()".

Instead of banking on TemporaryDirectory's auto-cleanup, you
might wanna take a stab at nuking the directory post-test with
a more bare-bones approach like os.rmdir() or roll your own
cleanup function.

Or you could wrap the TemporaryDirectory usage in a try-except
block to catch and log any hiccups during cleanup, so the
test can keep truckin' even if that cleanup goes sideways

[MRAB]

Post by c***@posteo.jp
Hello,
I am upstream maintainer of "Back In Time" [1] investigating an issue a
distro maintainer from Fedora reported [2] to me.
On one hand Fedora seems to use a tool called "mock" to build packages
in a chroot environment.
On the other hand the test suite of "Back In Time" does read and write
to the real file system.
One test fails because a temporary directory is cleaned up using
shutil.rmtree(). Please see the output below.
I am not familiar with Fedora and "mock". So I am not able to reproduce
this on my own.
It seems the Fedora maintainer also has no clue how to solve it or why
it happens.
Can you please have a look (especially at the line "assert func is
os.lstat").
Maybe you have an idea what is the intention behind this error raised by
an "assert" statement inside "shutil.rmtree()".
Thanks in advance,
Christian Buhtz
[1] -- <https://github.com/bit-team/backintime>
[2] -- <https://github.com/bit-team/backintime/issues/1911>
__________________________ General.test_ctor_defaults
__________________________
self = <test.test_uniquenessset.General testMethod=test_ctor_defaults>
"""Default values in constructor."""
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib64/python3.13/tempfile.py:946: in __exit__
self.cleanup()
/usr/lib64/python3.13/tempfile.py:950: in cleanup
self._rmtree(self.name, ignore_errors=self._ignore_cleanup_errors)
/usr/lib64/python3.13/tempfile.py:930: in _rmtree
_shutil.rmtree(name, onexc=onexc)
/usr/lib64/python3.13/shutil.py:763: in rmtree
_rmtree_safe_fd(stack, onexc)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
stack = []
onexc = <function TemporaryDirectory._rmtree.<locals>.onexc at
0xffffb39bc860>
# * func: The first operation to perform: os.lstat, os.close or
os.rmdir.
# Walking a directory starts with an os.lstat() to detect
symlinks; in
# this case, func is updated before subsequent operations and
passed to
# onexc() if an error occurs.
# * dirfd: Open file descriptor, or None if we're processing the
top-level
# directory given to rmtree() and the user didn't supply
dir_fd.
# * path: Path of file to operate upon. This is passed to
onexc() if an
# error occurs.
# * orig_entry: os.DirEntry, or None if we're processing the
top-level
# directory given to rmtree(). We used the cached stat() of
the entry to
# save a call to os.lstat() when walking subdirectories.
func, dirfd, path, orig_entry = stack.pop()
name = path if orig_entry is None else orig_entry.name
os.close(dirfd)
return
os.rmdir(name, dir_fd=dirfd)
return
# Note: To guard against symlink races, we use the standard
# lstat()/open()/fstat() trick.

assert func is os.lstat

E AssertionError
/usr/lib64/python3.13/shutil.py:663: AssertionError

What does "mock" do?

func should be either os.close, os.rmdir or os.lstat.

If mock is somehow replacing one of those functions, then it might break
the code.

[Left Right]

From reading the code where the exception is coming from, this is how

I interpret the intention of the author: they build a list (not sure
why they used list, when there's a stack datastructure in Python)
which they use as a stack, where the elements of the stack are
4-tuples, the important part about these tuples is that the first
element is the operation to be performed by rmtree() has to be one of
the known filesystem-related functions. The code raising the exception
checks that it's one of those kinds and if it isn't, crashes.

There is, however, a problem with testing equality (more strictly,
identity in this case) between functions. I.e. it's possible that a
function isn't identical to itself is, eg. "os" module was somehow
loaded twice. I'm not sure if that's a real possibility with how
Python works... but maybe in some cases, like, multithreaded
environments it could happen...

To investigate this, I'd edit the file with the assertion and make it
print the actual value found in os.lstat and func. My guess is that
they are both somehow "lstat", but with different memory addresses.

On Thu, Oct 24, 2024 at 4:06 PM Christian Buhtz via Python-list

Hello,
I am upstream maintainer of "Back In Time" [1] investigating an issue a
distro maintainer from Fedora reported [2] to me.
On one hand Fedora seems to use a tool called "mock" to build packages
in a chroot environment.
On the other hand the test suite of "Back In Time" does read and write
to the real file system.
One test fails because a temporary directory is cleaned up using
shutil.rmtree(). Please see the output below.
I am not familiar with Fedora and "mock". So I am not able to reproduce
this on my own.
It seems the Fedora maintainer also has no clue how to solve it or why
it happens.
Can you please have a look (especially at the line "assert func is
os.lstat").
Maybe you have an idea what is the intention behind this error raised by
an "assert" statement inside "shutil.rmtree()".
Thanks in advance,
Christian Buhtz
[1] -- <https://github.com/bit-team/backintime>
[2] -- <https://github.com/bit-team/backintime/issues/1911>
__________________________ General.test_ctor_defaults
__________________________
self = <test.test_uniquenessset.General testMethod=test_ctor_defaults>
"""Default values in constructor."""
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib64/python3.13/tempfile.py:946: in __exit__
self.cleanup()
/usr/lib64/python3.13/tempfile.py:950: in cleanup
self._rmtree(self.name, ignore_errors=self._ignore_cleanup_errors)
/usr/lib64/python3.13/tempfile.py:930: in _rmtree
_shutil.rmtree(name, onexc=onexc)
/usr/lib64/python3.13/shutil.py:763: in rmtree
_rmtree_safe_fd(stack, onexc)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
stack = []
onexc = <function TemporaryDirectory._rmtree.<locals>.onexc at
0xffffb39bc860>
# * func: The first operation to perform: os.lstat, os.close or
os.rmdir.
# Walking a directory starts with an os.lstat() to detect
symlinks; in
# this case, func is updated before subsequent operations and
passed to
# onexc() if an error occurs.
# * dirfd: Open file descriptor, or None if we're processing the
top-level
# directory given to rmtree() and the user didn't supply
dir_fd.
# * path: Path of file to operate upon. This is passed to
onexc() if an
# error occurs.
# * orig_entry: os.DirEntry, or None if we're processing the
top-level
# directory given to rmtree(). We used the cached stat() of
the entry to
# save a call to os.lstat() when walking subdirectories.
func, dirfd, path, orig_entry = stack.pop()
name = path if orig_entry is None else orig_entry.name
os.close(dirfd)
return
os.rmdir(name, dir_fd=dirfd)
return
# Note: To guard against symlink races, we use the standard
# lstat()/open()/fstat() trick.

assert func is os.lstat

E AssertionError
/usr/lib64/python3.13/shutil.py:663: AssertionError
--
https://mail.python.org/mailman/listinfo/python-list

[MRAB]

From reading the code where the exception is coming from, this is how
I interpret the intention of the author: they build a list (not sure
why they used list, when there's a stack datastructure in Python)
which they use as a stack, where the elements of the stack are
4-tuples, the important part about these tuples is that the first
element is the operation to be performed by rmtree() has to be one of
the known filesystem-related functions. The code raising the exception
checks that it's one of those kinds and if it isn't, crashes.
There is, however, a problem with testing equality (more strictly,
identity in this case) between functions. I.e. it's possible that a
function isn't identical to itself is, eg. "os" module was somehow
loaded twice. I'm not sure if that's a real possibility with how
Python works... but maybe in some cases, like, multithreaded
environments it could happen...
To investigate this, I'd edit the file with the assertion and make it
print the actual value found in os.lstat and func. My guess is that
they are both somehow "lstat", but with different memory addresses.

The stack is created on line 760 with os.lstat and entries are appended
on lines 677 (os.rmdir), 679 (os.close) and 689 (os.lstat).

'func' is popped off the stack on line 651 and check in the following lines.

I can't see anywhere else where something else is put onto the stack or
an entry is replaced.

On Thu, Oct 24, 2024 at 4:06 PM Christian Buhtz via Python-list

Post by c***@posteo.jp
Hello,
I am upstream maintainer of "Back In Time" [1] investigating an issue a
distro maintainer from Fedora reported [2] to me.
On one hand Fedora seems to use a tool called "mock" to build packages
in a chroot environment.
On the other hand the test suite of "Back In Time" does read and write
to the real file system.
One test fails because a temporary directory is cleaned up using
shutil.rmtree(). Please see the output below.
I am not familiar with Fedora and "mock". So I am not able to reproduce
this on my own.
It seems the Fedora maintainer also has no clue how to solve it or why
it happens.
Can you please have a look (especially at the line "assert func is
os.lstat").
Maybe you have an idea what is the intention behind this error raised by
an "assert" statement inside "shutil.rmtree()".
Thanks in advance,
Christian Buhtz
[1] -- <https://github.com/bit-team/backintime>
[2] -- <https://github.com/bit-team/backintime/issues/1911>
__________________________ General.test_ctor_defaults
__________________________
self = <test.test_uniquenessset.General testMethod=test_ctor_defaults>
"""Default values in constructor."""
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib64/python3.13/tempfile.py:946: in __exit__
self.cleanup()
/usr/lib64/python3.13/tempfile.py:950: in cleanup
self._rmtree(self.name, ignore_errors=self._ignore_cleanup_errors)
/usr/lib64/python3.13/tempfile.py:930: in _rmtree
_shutil.rmtree(name, onexc=onexc)
/usr/lib64/python3.13/shutil.py:763: in rmtree
_rmtree_safe_fd(stack, onexc)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
stack = []
onexc = <function TemporaryDirectory._rmtree.<locals>.onexc at
0xffffb39bc860>
# * func: The first operation to perform: os.lstat, os.close or
os.rmdir.
# Walking a directory starts with an os.lstat() to detect
symlinks; in
# this case, func is updated before subsequent operations and
passed to
# onexc() if an error occurs.
# * dirfd: Open file descriptor, or None if we're processing the
top-level
# directory given to rmtree() and the user didn't supply
dir_fd.
# * path: Path of file to operate upon. This is passed to
onexc() if an
# error occurs.
# * orig_entry: os.DirEntry, or None if we're processing the
top-level
# directory given to rmtree(). We used the cached stat() of
the entry to
# save a call to os.lstat() when walking subdirectories.
func, dirfd, path, orig_entry = stack.pop()
name = path if orig_entry is None else orig_entry.name
os.close(dirfd)
return
os.rmdir(name, dir_fd=dirfd)
return
# Note: To guard against symlink races, we use the standard
# lstat()/open()/fstat() trick.

assert func is os.lstat

E AssertionError
/usr/lib64/python3.13/shutil.py:663: AssertionError
--
https://mail.python.org/mailman/listinfo/python-list

[MRAB]

Post by MRAB
The stack is created on line 760 with os.lstat and entries are appended
on lines 677 (os.rmdir), 679 (os.close) and 689 (os.lstat).
'func' is popped off the stack on line 651 and check in the following lines.
I can't see anywhere else where something else is put onto the stack or
an entry is replaced.

But how do you know this code isn't executed from different threads?
What I anticipate to be the problem is that the "os" module is
imported twice, and there are two references to "os.lstat". Normally,
this wouldn't cause a problem, because they are the same function that
doesn't have any state, but once you are trying to compare them, the
identity test will fail, because those functions were loaded multiple
times into different memory locations.
I don't know of any specific mechanism for forcing the interpreter to
import the same module multiple times, but if that was possible (which
in principle it is), then it would explain the behavior.

The stack is a local variable and os.lstat, etc, are pushed and popped
in one function and then another that it calls, so they're in the same
thread.

[Left Right]

Post by MRAB
The stack is created on line 760 with os.lstat and entries are appended
on lines 677 (os.rmdir), 679 (os.close) and 689 (os.lstat).
'func' is popped off the stack on line 651 and check in the following lines.
I can't see anywhere else where something else is put onto the stack or
an entry is replaced.

But how do you know this code isn't executed from different threads?
What I anticipate to be the problem is that the "os" module is
imported twice, and there are two references to "os.lstat". Normally,
this wouldn't cause a problem, because they are the same function that
doesn't have any state, but once you are trying to compare them, the
identity test will fail, because those functions were loaded multiple
times into different memory locations.

I don't know of any specific mechanism for forcing the interpreter to
import the same module multiple times, but if that was possible (which
in principle it is), then it would explain the behavior.

[Left Right]

Post by MRAB
The stack is created on line 760 with os.lstat and entries are appended
on lines 677 (os.rmdir), 679 (os.close) and 689 (os.lstat).
'func' is popped off the stack on line 651 and check in the following lines.
I can't see anywhere else where something else is put onto the stack or
an entry is replaced.

But the _rmtree_safe_fd() compares func to a *dynamically* resolved
reference: os.lstat. If the reference to os changed (or os object was
modified to have new reference at lstat) between the time os.lstat was
added to the stack and the time of comparison, then comparison
would've failed. To illustrate my idea:

os.lstat = lambda x: x # thread 1
stack.append((os.lstat, ...)) # thread 1
os.lstat = lambda x: x # thread 2
func, *_ = stack.pop() # thread 1
assert func is os.lstat # thread 1 (failure!)

The only question is: is it possible to modify os.lstat like that, and
if so, how?

Other alternatives include a malfunctioning "is" operator,
malfunctioning module cache... all those are a lot less likely.

[MRAB]

Post by Left Right

Post by MRAB
The stack is created on line 760 with os.lstat and entries are appended
on lines 677 (os.rmdir), 679 (os.close) and 689 (os.lstat).
'func' is popped off the stack on line 651 and check in the following lines.
I can't see anywhere else where something else is put onto the stack or
an entry is replaced.

But the _rmtree_safe_fd() compares func to a *dynamically* resolved
reference: os.lstat. If the reference to os changed (or os object was
modified to have new reference at lstat) between the time os.lstat was
added to the stack and the time of comparison, then comparison
os.lstat = lambda x: x # thread 1
stack.append((os.lstat, ...)) # thread 1
os.lstat = lambda x: x # thread 2
func, *_ = stack.pop() # thread 1
assert func is os.lstat # thread 1 (failure!)
The only question is: is it possible to modify os.lstat like that, and
if so, how?
Other alternatives include a malfunctioning "is" operator,
malfunctioning module cache... all those are a lot less likely.

What is the probability of replacing os.lstat, os.close or os.rmdir from
another thread at just the right time?

[Left Right]

Post by MRAB
What is the probability of replacing os.lstat, os.close or os.rmdir from
another thread at just the right time?

If the thead does "import os", and its start is logically connected to
calling _rmtree_safe_fd(), I'd say it's a very good chance! That is,
again, granted that the reference to os.lstat *can* be modified in
this way.

But, before we keep guessing any further, it'd be best if OP could get
us the info on what's stored in "func" and "os.lstat" at the time the
assertion fails.

[2***@potatochowder.com]

On 2024-10-24 at 20:54:53 +0100,

Post by MRAB

Post by Left Right

Post by MRAB
The stack is created on line 760 with os.lstat and entries are appended
on lines 677 (os.rmdir), 679 (os.close) and 689 (os.lstat).
'func' is popped off the stack on line 651 and check in the following lines.
I can't see anywhere else where something else is put onto the stack or
an entry is replaced.

But the _rmtree_safe_fd() compares func to a *dynamically* resolved
reference: os.lstat. If the reference to os changed (or os object was
modified to have new reference at lstat) between the time os.lstat was
added to the stack and the time of comparison, then comparison
os.lstat = lambda x: x # thread 1
stack.append((os.lstat, ...)) # thread 1
os.lstat = lambda x: x # thread 2
func, *_ = stack.pop() # thread 1
assert func is os.lstat # thread 1 (failure!)
The only question is: is it possible to modify os.lstat like that, and
if so, how?
Other alternatives include a malfunctioning "is" operator,
malfunctioning module cache... all those are a lot less likely.

What is the probability of replacing os.lstat, os.close or os.rmdir from
another thread at just the right time?

That is never the right question in a multi-threaded system. The answer
is always that is doesn't matter, the odds will beat you in the end. Or
sometimes right in the middle of a CPU instruction; does anyone remember
the MC680XX series?

Yes, as a matter of fact, I did used to make my living designing,
building, delivering, and maintaining such systems.

[Barry]

On one hand Fedora seems to use a tool called "mock" to build packages in a chroot environment.
On the other hand the test suite of "Back In Time" does read and write to the real file system.

I am a Fedora packager and can help explain what is the tools are doing.

Mock runs the build in a chroot env that allows for reproducible clean room builds.
Sort like a container.

This is nothing to do with the python mock package.

What do you mean by the real file sustem?

You cannot write to the /usr file system. Is that what your tests do?
If so that needs changing.

Barry

[c***@posteo.jp]

Thank you very much for all your responses.

Post by Left Right
To investigate this, I'd edit the file with the assertion and make it
print the actual value found in os.lstat and func. My guess is that
they are both somehow "lstat", but with different memory addresses.

My reporter provided this [1]. I think this is the relevant output:

=========================== short test summary info
============================
FAILED test/test_plugin_usercallback.py::SystemTest::test_local_snapshot
- As...
FAILED test/test_uniquenessset.py::General::test_ctor_defaults -
AssertionError
FAILED test/test_uniquenessset.py::General::test_deep_check -
AssertionError
FAILED
test/test_uniquenessset.py::General::test_fail_equal_without_equal_to
FAILED test/test_uniquenessset.py::General::test_size_mtime -
AssertionError
FAILED test/test_uniquenessset.py::General::test_unique_myself -
AssertionError
FAILED
test/test_uniquenessset.py::General::test_unique_size_but_different_mtime
================== 7 failed, 267 passed, 16 skipped in 20.79s
==================
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
os.lstat=<built-in function lstat>
make: Leaving directory
'/home/johannes/rpmbuild/BUILD/backintime-1.5.3-build/backintime-1.5.3-rc1/common'

RPM build errors:



[1] --
<https://github.com/bit-team/backintime/issues/1911#issuecomment-2436851901>

[c***@posteo.jp]

Hello Barry,

thank you for your reply and clarifying the Fedora aspects.

Post by Barry
What do you mean by the real file sustem?
You cannot write to the /usr file system. Is that what your tests do?
If so that needs changing.

Asking the right questions brings up to important details. While I was
writing and trying to explain that the relevant test does use
""tempfile.TemporaryDirectory" as a context, I realized that "PyFakeFS"
is used in the back [1].

But that makes me wonder. On a "regular" system all tests are running.
So the issue might exist because of a combination of 3 factors:
shutil.rmtree(), PyFakeFS in a chroot/mock build environment.

[1] --
<https://github.com/bit-team/backintime/blob/c1d042ab67b9e117ac53e944518a0f4292fa075b/common/test/test_uniquenessset.py#L45>

[c***@posteo.jp]

Post by c***@posteo.jp
On a "regular" system all tests are running.

To clarify: "regular" does not exclude PyFakeFS. It means on my own
local development machine and on the TravsCI machines (Ubuntu 22 with
Python 3.9 up to 3.13) and using PyFakeFS in that test, everything is
fine.
Only when mock/chroot is involved that happens.

[c***@posteo.jp]

As you can see in the linked issue it seems it was an incompatibility
between the version of Python and PyFakeFS.

In the end it was a Fedora packaging bug because that pyfakefs version
was not compatible with Python 3.13.

Thanks in advance for helping out.

[Barry]

Post by c***@posteo.jp
As you can see in the linked issue it seems it was an incompatibility
between the version of Python and PyFakeFS.
In the end it was a Fedora packaging bug because that pyfakefs version
was not compatible with Python 3.13.

That makes sense.

Post by c***@posteo.jp
Thanks in advance for helping out.

No problem.

Barry

Post by c***@posteo.jp
--
https://mail.python.org/mailman/listinfo/python-list