You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
in Debian we backported the changes from #27926 to cpython 3.10 and indeed most pyc files that we generate when installing python packages are now bit-by-bit reproducible. There is only a single pyc file that still sometimes leads to a different pyc file after installation: /usr/lib/python3.10/json/__pycache__/decoder.cpython-310.pyc. I tracked down the reason to its use of the variable name _m and filed this as Debian bug 1010368. More specifically, that pyc file will have one content in 1/3 cases and another in 2/3 of the cases. The diff between the pyc files is:
With that patch, python files containing the variable name _b are now sometimes unreproducible.
I don't seem to be the first who stumbled across the _m variable: #78903 (comment)
In the Debian bug I referenced above, Chris Lamb states, that there is no semantic difference between the different pyc files and Keith Amling points out, that the difference is FLAG_REF being added or not.
Since pyc files containing the variable _m are only sometimes unreproducible on new python installations but stable on the same installation, this might as well be a python packaging bug in Debian or maybe we need to backport more than just #27926 to 3.10 to make pyc files stable across different installations. I thus wanted to ask you for any input or advice you can give on this issue.
Thanks!
The text was updated successfully, but these errors were encountered:
Thanks! I backported the changes to Python/marshal.c from #8226 to python 3.10 in Debian and can confirm that those changes fix this particular problem.
@methane do you think that #8226 has a chance to be merged soon?
Hi,
in Debian we backported the changes from #27926 to cpython 3.10 and indeed most pyc files that we generate when installing python packages are now bit-by-bit reproducible. There is only a single pyc file that still sometimes leads to a different pyc file after installation:
/usr/lib/python3.10/json/__pycache__/decoder.cpython-310.pyc
. I tracked down the reason to its use of the variable name_m
and filed this as Debian bug 1010368. More specifically, that pyc file will have one content in 1/3 cases and another in 2/3 of the cases. The diff between the pyc files is:I can make this problem trigger on a different variable name than
_m
via the following patch:With that patch, python files containing the variable name
_b
are now sometimes unreproducible.I don't seem to be the first who stumbled across the
_m
variable: #78903 (comment)In the Debian bug I referenced above, Chris Lamb states, that there is no semantic difference between the different pyc files and Keith Amling points out, that the difference is
FLAG_REF
being added or not.Since pyc files containing the variable
_m
are only sometimes unreproducible on new python installations but stable on the same installation, this might as well be a python packaging bug in Debian or maybe we need to backport more than just #27926 to 3.10 to make pyc files stable across different installations. I thus wanted to ask you for any input or advice you can give on this issue.Thanks!
The text was updated successfully, but these errors were encountered: