Description of problem: Attempting system upgrade... dnf upgrade gave error messages about file ownership (see below) Version-Release number of selected component (if applicable): see below How reproducible: Always. Steps to Reproduce: 1.dnf upgrade 2. 3. Actual results: Transaction failed: Rpm transaction failed. - file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.opt-1.pyc conflicts between attempted installs of libstdc++-14.1.1-6.fc41.i686 and libstdc++-14.1.1-6.fc41.x86_64 - file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.pyc conflicts between attempted installs of libstdc++-14.1.1-6.fc41.i686 and libstdc++-14.1.1-6.fc41.x86_64 - file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-313.opt-1.pyc conflicts between attempted installs of libstdc++-14.1.1-6.fc41.i686 and libstdc++-14.1.1-6.fc41.x86_64 - file /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-313.pyc conflicts between attempted installs of libstdc++-14.1.1-6.fc41.i686 and libstdc++-14.1.1-6.fc41.x86_64 Expected results: Clean system upgrade Additional info: Component listing during the creation of this bug report failed to identify a component: dnf provides /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.opt-1.pyc Updating and loading repositories: Fedora - Rawhide - Developmental packages for the next Fedora release 100% | 142.4 KiB/s | 58.3 MiB | 06m59s Opera packages 100% | 3.5 KiB/s | 11.1 KiB | 00m03s google-chrome 100% | 1.1 KiB/s | 6.8 KiB | 00m06s RPM Fusion for Fedora Rawhide - Nonfree 100% | 53.6 KiB/s | 443.9 KiB | 00m08s RPM Fusion for Fedora Rawhide - Free 100% | 74.7 KiB/s | 658.2 KiB | 00m09s Repositories loaded. libstdc++-14.1.1-6.fc41.i686 : GNU Standard C++ Library Repo : rawhide Matched From : Filename : /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.opt-1.pyc libstdc++-14.1.1-6.fc41.x86_64 : GNU Standard C++ Library Repo : rawhide Matched From : Filename : /usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.opt-1.pyc
From the build.log: + /usr/bin/add-determinism --brp -j48 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT ... /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-313.opt-1.pyc: replacing with normalized version ... /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-313.pyc: replacing with normalized version /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.pyc: replacing with normalized version /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.opt-1.pyc: replacing with normalized version If I needed to guess, the "normalized version" on i686 is different from the "normalized version" on x86_64. Which is kinda against the idea of add-determinism. Reassigning to add-determinism, but gcc needs to be rebuilt once add-determinism is fixed.
From the chat on fedora-devel matrix channel: $ ls -l {a,b}/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.pyc -rw-r--r--. 1 zbyszek zbyszek 146285 Jun 24 20:23 a/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.pyc -rw-r--r--. 1 zbyszek zbyszek 146280 Jun 24 20:23 b/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.pyc Marshalparser and add-determinism don't change the size of the files. The files have different size, which means that they must have somehow different contents (both before and after the normalization phase).
FWIW gcc seems to have a custom in-spec Python bytecompilation stuff: https://src.fedoraproject.org/rpms/gcc/blob/rawhide/f/gcc.spec#_1691 for f in `find %{buildroot}%{_prefix}/share/gcc-%{gcc_major}/python/ \ %{buildroot}%{_datadir}/gdb/auto-load/%{_prefix}/%{_lib}/ -name \*.py`; do r=${f/$RPM_BUILD_ROOT/} %{__python3} -c 'import py_compile; py_compile.compile("'$f'", dfile="'$r'")' %{__python3} -O -c 'import py_compile; py_compile.compile("'$f'", dfile="'$r'")' done I am not sure why it is not using %py_byte_compile as documented in https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#manual-bytecompilation That makes me think the .pycs will have hash-based invalidation mode rather than clamped-mtime-based. However, that might not be the cause of this.
Relevant lines from the log: + /usr/bin/python3 -c 'import py_compile; py_compile.compile("/builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/printers.py", dfile="/usr/share/gcc-14/python/libstdcxx/v6/printers.py")' + /usr/bin/python3 -O -c 'import py_compile; py_compile.compile("/builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/printers.py", dfile="/usr/share/gcc-14/python/libstdcxx/v6/printers.py")' ... + /usr/bin/python3 -c 'import py_compile; py_compile.compile("/builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/xmethods.py", dfile="/usr/share/gcc-14/python/libstdcxx/v6/xmethods.py")' + /usr/bin/python3 -O -c 'import py_compile; py_compile.compile("/builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/xmethods.py", dfile="/usr/share/gcc-14/python/libstdcxx/v6/xmethods.py")' We can try reproducing this in mock on x86_64 and i686 and see if the produced .pyc files are different sizes or not.
1. copy the two files into x86_64 and i686 mocks to /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/ 2. install python3-devel, shell into the mocks 3. export SOURCE_DATE_EPOCH=1718841600 4. run the 4 code snippets from the above 5. ls -l the results fedora-rawhide-i386: -rw-r--r--. 1 mockbuild mock 146273 Jun 27 00:02 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.opt-1.pyc -rw-r--r--. 1 mockbuild mock 146285 Jun 27 00:02 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.pyc -rw-r--r--. 1 mockbuild mock 50524 Jun 27 00:02 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-313.opt-1.pyc -rw-r--r--. 1 mockbuild mock 50531 Jun 27 00:02 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-313.pyc fedora-rawhide-x86_64: -rw-r--r--. 1 mockbuild mock 146285 Jun 27 00:02 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.opt-1.pyc -rw-r--r--. 1 mockbuild mock 146261 Jun 27 00:02 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.pyc -rw-r--r--. 1 mockbuild mock 50517 Jun 27 00:02 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-313.opt-1.pyc -rw-r--r--. 1 mockbuild mock 50538 Jun 27 00:02 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-313.pyc The sizes differ. Now run what the actual macro runs instead: <mock-chroot> sh-5.2$ rm -rf /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__ <mock-chroot> sh-5.2$ export RPM_BUILD_ROOT=/builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT <mock-chroot> sh-5.2$ python_binary="env PYTHONHASHSEED=0 /usr/bin/python3" <mock-chroot> sh-5.2$ bytecode_compilation_path="/builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6" <mock-chroot> sh-5.2$ $python_binary -s -B -m compileall -j8 -o 0 -o 1 -s $RPM_BUILD_ROOT -p / --hardlink-dupes --invalidation-mode=timestamp $bytecode_compilation_path Listing '/builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6'... Compiling '/builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/printers.py'... Compiling '/builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/xmethods.py'... <mock-chroot> sh-5.2$ ls -l /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/* -rw-r--r--. 1 mockbuild mock 146624 Jun 27 00:13 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.opt-1.pyc -rw-r--r--. 1 mockbuild mock 146285 Jun 27 00:13 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-313.pyc -rw-r--r--. 2 mockbuild mock 50531 Jun 27 00:13 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-313.opt-1.pyc -rw-r--r--. 2 mockbuild mock 50531 Jun 27 00:13 /builddir/build/BUILD/gcc-14.1.1-build/BUILDROOT/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-313.pyc The sizes are the same on both architectures. Ergo, I think the gcc custom Python bytecompilation is the cause. Further experiment show that it is missing PYTHONHASHSEED=0 that causes this. gcc should be fixable by either setting PYTHONHASHSEED=0 when running custom bytecompilation or better yet following the packaging guidelines wrt Python bytecompilation.
*** Bug 2293940 has been marked as a duplicate of this bug. ***
I believe the proper invocation to replace the for-find-compile snippet would be: %py_byte_compile %{python3} %{buildroot}%{_prefix}/share/gcc-%{gcc_major}/python/ %py_byte_compile %{python3} %{buildroot}%{_datadir}/gdb/auto-load/%{_prefix}/%{_lib}/ This will give you .pycs of the same length and meaning, but they are not guaranteed to be bit-by-bit identical. On Fedora 41+, add-determinism makes such .pycs bit-by-bit identical. On older Fedoras, RHELs (and today also on ELN), you also need to follow https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#_byte_compilation_reproducibility to use marshalparser to make them bit-by-bit identical, or the same problem (conflicting files) may happen again one day.
Isn't this already fixed in Py3.11+? <https://github.com/python/cpython/pull/27926> Or was this a regression in Py3.13?
I don't know. We support the documented way.
I started an i686 and x86_64 builds with the patch. I'll submit a PR if the result is good.
(In reply to Zephyr Lykos from comment #8) > Isn't this already fixed in Py3.11+? > <https://github.com/python/cpython/pull/27926> > Or was this a regression in Py3.13? The test still exists and still passes on Python 3.13: https://github.com/python/cpython/blob/3.13/Lib/test/test_marshal.py#L376
https://src.fedoraproject.org/rpms/gcc/pull-request/55 I didn't do any extensive testing, but the offending files that were listed in the original description above are identical between x86_64 and i686 builds.
*** Bug 2294845 has been marked as a duplicate of this bug. ***
The manual bytecode compilation has been added there in August 2016 to work around python3-devel bugs, I think #1204355 and #1204355. I'll apply the PR, thanks.
*** Bug 2293774 has been marked as a duplicate of this bug. ***
*** Bug 2293782 has been marked as a duplicate of this bug. ***
FEDORA-2024-3d923ca4a5 (gcc-14.1.1-7.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-3d923ca4a5
FEDORA-2024-3d923ca4a5 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-3d923ca4a5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-3d923ca4a5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-3d923ca4a5 (gcc-14.1.1-7.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
Why the new libstdc++ still not pushed to Rawhide repo? I expect to see this packages https://koji.fedoraproject.org/koji/taskinfo?taskID=119856232
(In reply to Mikhail from comment #20) > Why the new libstdc++ still not pushed to Rawhide repo? > I expect to see this packages > https://koji.fedoraproject.org/koji/taskinfo?taskID=119856232 Probably still in the release engineering pipe. The respective update: https://bodhi.fedoraproject.org/updates/FEDORA-2024-b75ebd7282 was set ready a day ago...