Description of problem: SELinux is preventing gdb from 'write' accesses on the directory /usr/share/gcc-5.0.0/python/libstdcxx/v6/__pycache__. ***** Plugin catchall_labels (83.8 confidence) suggests ******************* If you want to allow gdb to have write access on the __pycache__ directory Then you need to change the label on /usr/share/gcc-5.0.0/python/libstdcxx/v6/__pycache__ Do # semanage fcontext -a -t FILE_TYPE '/usr/share/gcc-5.0.0/python/libstdcxx/v6/__pycache__' where FILE_TYPE is one of the following: abrt_tmp_t, abrt_upload_watch_tmp_t, abrt_var_cache_t, abrt_var_log_t, abrt_var_run_t, mock_var_lib_t, rpm_var_cache_t, rpm_var_run_t, sosreport_tmp_t, tmp_t, var_log_t, var_run_t, var_spool_t, var_t. Then execute: restorecon -v '/usr/share/gcc-5.0.0/python/libstdcxx/v6/__pycache__' ***** Plugin catchall (17.1 confidence) suggests ************************** If you believe that gdb should be allowed write access on the __pycache__ directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep gdb /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:abrt_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:usr_t:s0 Target Objects /usr/share/gcc-5.0.0/python/libstdcxx/v6/__pycache __ [ dir ] Source gdb Source Path gdb Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-118.fc22.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.0.0-0.rc4.git0.1.fc22.x86_64+debug #1 SMP Mon Mar 16 14:17:56 UTC 2015 x86_64 x86_64 Alert Count 2 First Seen 2015-03-21 14:22:55 YEKT Last Seen 2015-03-21 14:22:55 YEKT Local ID 6bd6a6ca-4fc4-4459-a763-f7a55ea7390f Raw Audit Messages type=AVC msg=audit(1426929775.380:607): avc: denied { write } for pid=10388 comm="gdb" name="__pycache__" dev="sda1" ino=404659 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:usr_t:s0 tclass=dir permissive=0 Hash: gdb,abrt_t,usr_t,dir,write Version-Release number of selected component: selinux-policy-3.13.1-118.fc22.noarch Additional info: reporter: libreport-2.5.0 hashmarkername: setroubleshoot kernel: 4.0.0-0.rc4.git0.1.fc22.x86_64+debug type: libreport Potential duplicate: bug 665543
This is issue with missing python flags during build.
What python flags do you mean?
There was a discussion about it #528554.
Description of problem: Happened when abrt ran after a crash. Version-Release number of selected component: selinux-policy-3.13.1-122.fc22.noarch Additional info: reporter: libreport-2.5.1 hashmarkername: setroubleshoot kernel: 4.0.0-1.fc22.x86_64 type: libreport
Description of problem: Was replying to an email in evolution when it crashed. I think this avc came up when abrt tried to analyse the crash. Version-Release number of selected component: selinux-policy-3.13.1-126.fc22.noarch Additional info: reporter: libreport-2.5.1 hashmarkername: setroubleshoot kernel: 4.0.4-300.fc22.x86_64 type: libreport
Description of problem: nemo crashed and abrt is prowerless to report it :-) , Please take as long as yo like to fix as it will save bugzilla plaguing me with abrt repots. Version-Release number of selected component: selinux-policy-3.13.1-126.fc22.noarch Additional info: reporter: libreport-2.5.1 hashmarkername: setroubleshoot kernel: 4.0.4-301.fc22.x86_64 type: libreport
I am seeing this bug too. I don't think this is a bug in glib but libreport or gdb. Can someone please reassign this bug to libreport?
Your wish is my command...
Marek Brysa noticed that the AVC occurred with Python3 (__pycache__) and I found out that gdb switched from Python2 to Python3 few months ago (bug #1014549), so the packages shipping gdb python files have to switch from Python2 to Python3 too (bug #1014549 comment #3).
(In reply to Jakub Filak from comment #9) > Marek Brysa noticed that the AVC occurred with Python3 (__pycache__) and I > found out that gdb switched from Python2 to Python3 few months ago (bug > #1014549), so the packages shipping gdb python files have to switch from > Python2 to Python3 too (bug #1014549 comment #3). The gdb printers in gcc already work with both python2 and python3 (the comment you linked to is nearly two years old). What else does "switch from Python2 to Python3" require?
(In reply to Jonathan Wakely from comment #10) > The gdb printers in gcc already work with both python2 and python3 (the > comment you linked to is nearly two years old). What else does "switch from > Python2 to Python3" require? I think you need to byte compile *.py files with python 3 [1], because the file list of libstc++ already contains the line "%{_prefix}/share/gcc-%{gcc_version}/python/libstdcxx" (the directory and its contents). 1: https://fedoraproject.org/wiki/Packaging:Python#Bytecompiling_with_the_correct_python_version
which *.py files? those by gdb? or libstdc++?
$ rpm -qf /usr/share/gcc-5.1.1/python/libstdcxx/v6 libstdc++-5.1.1-4.fc22.x86_64 so it looks like libstdc++ (There are Python 2's *.pyc, but no Python 3's __pycache__/*.pyc.)
Right, libstdc++ files. $ rpm -qf /usr/share/gcc-5.2.1/python/libstdcxx/v6/printers.py libstdc++-5.2.1-5.fc24.x86_64 $ rpm -qf /usr/share/gcc-5.2.1/python/libstdcxx/v6/__pycache__/printers.cpython-34.pyc file /usr/share/gcc-5.2.1/python/libstdcxx/v6/__pycache__/printers.cpython-34.pyc is not owned by any package gdb auto-loads the /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.21-gdb.py file and the file imports the libstdcxx.v6 python module. If you run gdb as root, the __pycache__ directory will be created.
*** Bug 1278188 has been marked as a duplicate of this bug. ***
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Still an issue with F23 (see the dup)
Created attachment 1182851 [details] A patch that byte compiles gdb python files The patch should create all the files that are created by Python runtime otherwise.
(In reply to Jakub Filak from comment #18) Files and directories added by the patch on my Rawhide box: $ rpm -qlp /home/repos/fedora/gcc/x86_64/libstdc++-6.1.1-4.fc25.x86_64.rpm | grep __pycache__ /usr/share/gcc-6.1.1/python/libstdcxx/__pycache__ /usr/share/gcc-6.1.1/python/libstdcxx/__pycache__/__init__.cpython-35.opt-1.pyc /usr/share/gcc-6.1.1/python/libstdcxx/__pycache__/__init__.cpython-35.pyc /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__ /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__/__init__.cpython-35.opt-1.pyc /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__/__init__.cpython-35.pyc /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__/printers.cpython-35.opt-1.pyc /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__/printers.cpython-35.pyc /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__/xmethods.cpython-35.opt-1.pyc /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__/xmethods.cpython-35.pyc /usr/share/gdb/auto-load/usr/lib64/__pycache__ /usr/share/gdb/auto-load/usr/lib64/__pycache__/libstdc++.so.6.0.22-gdb.cpython-35.opt-1.pyc /usr/share/gdb/auto-load/usr/lib64/__pycache__/libstdc++.so.6.0.22-gdb.cpython-35.pyc
Error: Transaction check error: file /usr/share/gcc-6.1.1/python/libstdcxx/__pycache__/__init__.cpython-35.opt-1.pyc conflicts between attempted installs of libstdc++-6.1.1-5.fc26.i686 and libstdc++-6.1.1-5.fc26.x86_64 file /usr/share/gcc-6.1.1/python/libstdcxx/__pycache__/__init__.cpython-35.pyc conflicts between attempted installs of libstdc++-6.1.1-5.fc26.i686 and libstdc++-6.1.1-5.fc26.x86_64 file /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__/__init__.cpython-35.opt-1.pyc conflicts between attempted installs of libstdc++-6.1.1-5.fc26.i686 and libstdc++-6.1.1-5.fc26.x86_64 file /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__/__init__.cpython-35.pyc conflicts between attempted installs of libstdc++-6.1.1-5.fc26.i686 and libstdc++-6.1.1-5.fc26.x86_64 file /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__/printers.cpython-35.opt-1.pyc conflicts between attempted installs of libstdc++-6.1.1-5.fc26.i686 and libstdc++-6.1.1-5.fc26.x86_64 file /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__/printers.cpython-35.pyc conflicts between attempted installs of libstdc++-6.1.1-5.fc26.i686 and libstdc++-6.1.1-5.fc26.x86_64 file /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__/xmethods.cpython-35.opt-1.pyc conflicts between attempted installs of libstdc++-6.1.1-5.fc26.i686 and libstdc++-6.1.1-5.fc26.x86_64 file /usr/share/gcc-6.1.1/python/libstdcxx/v6/__pycache__/xmethods.cpython-35.pyc conflicts between attempted installs of libstdc++-6.1.1-5.fc26.i686 and libstdc++-6.1.1-5.fc26.x86_64
Ugh, so python 3 bytecode is wordsize dependent while python 2 bytecode is not? At least no multilib issues were reported before and libstdc++ shipped python 2 bytecode for quite some time. Or does it store timestamps rather than filestamps?
Ah, no, but it stores there the full pathname and that in this case includes also the %{buildroot}, which is different. FPC pages recommend %py_byte_compile %{__python3} %{buildroot}%{_datadir}/mypackage/bar so that looks like python3-devel bug to me. In the build log, I'm seeing + python_binary=/usr/bin/python3 + bytecode_compilation_path=/builddir/build/BUILDROOT/gcc-6.1.1-5.fc26.x86_64/usr/share/gcc-6.1.1/python/ + find /builddir/build/BUILDROOT/gcc-6.1.1-5.fc26.x86_64/usr/share/gcc-6.1.1/python/ -type f -a -name '*.py' -print0 + xargs -0 /usr/bin/python3 -c 'import py_compile, sys; [py_compile.compile(f, dfile=f.partition("$RPM_BUILD_ROOT")[2]) for f in sys.argv[1:]]' which comes from python3-devel's /usr/lib/rpm/macros.d/macros.pybytecompile # Note that the path could itself be a python file, or a directory # Python's compile_all module only works on directories, and requires a max # recursion depth %py_byte_compile()\ python_binary="%1"\ bytecode_compilation_path="%2"\ find $bytecode_compilation_path -type f -a -name "*.py" -print0 | xargs -0 $python_binary -c 'import py_compile, sys; [py_compile.compile(f, dfile=f.partition("$RPM_BUILD_ROOT")[2]) for f in sys.argv[1:]]' || :\ \ find $bytecode_compilation_path -type f -a -name "*.py" -print0 | xargs -0 $python_binary -O -c 'import py_compile, sys; [py_compile.compile(f, dfile=f.partition("$RPM_BUILD_ROOT")[2]) for f in sys.argv[1:]]' || :\ %{nil} That $RPM_BUILD_ROOT in there looks weird to me, I'd have expected %{buildroot} instead (so that it is substituted by rpm already), or '$RPM_BUILD_ROOT', so it is expanded by the shell, which otherwise is inside of single quotes. But my python knowledge is dated...
I 've tried: Summary: Test for pyc Name: pyctest Version: 0.1 Release: 1%{?dist} License: GPLv2+ BuildRequires: python3-devel %description Test %prep %build %install mkdir -p %{buildroot}/tmp/abcd echo > %{buildroot}/tmp/abcd/test.py #py_byte_compile %{__python3} %{buildroot}/tmp/abcd %{__python3} -c 'import compileall, sys; sys.exit(not compileall.compile_dir("%{buildroot}/tmp/abcd", 4, "/tmp/abcd", force=1, quiet=1))' %{__python3} -O -c 'import compileall, sys; sys.exit(not compileall.compile_dir("%{buildroot}/tmp/abcd", 4, "/tmp/abcd", force=1, quiet=1))' %files %defattr(-,root,root) /tmp/abcd %changelog * Thu Aug 11 2016 Jakub Jelinek <jakub> 0.1-1 - new package and neither with the s/#py_byte/%py_byte/ method, nor the manual one copied from /usr/lib/rpm/brp-python-bytecompile , python3 seems to always stick the full pathname including %{buildroot}. Is there a way to convince python3 not to do that and store just /tmp/abcd.py or say a relative path?
Multilib conflicts for .pyc files are often a timestamp issue: python bytecode files embed the timestamp of the corresponding .py file, so if this .py files have different timestamps across peer builds, then the .pyc files won't be bit-for-bit identical. Do the .py files get patched anywhere in the build? If so, try resetting the timestamp of the .py file to that of the archive somewhere in the specfile before the byte-compilation happens.
(In reply to Dave Malcolm from comment #24) > Multilib conflicts for .pyc files are often a timestamp issue: python > bytecode files embed the timestamp of the corresponding .py file, so if this > .py files have different timestamps across peer builds, then the .pyc files > won't be bit-for-bit identical. > > Do the .py files get patched anywhere in the build? If so, try resetting > the timestamp of the .py file to that of the archive somewhere in the > specfile before the byte-compilation happens. The mtime of a .py file is embedded at the top of the corresponding bytecompiled python files (.pyc/.pyo). Hence, if you see multilib problems with nonequal .pyc/.pyo files, it's probably due to mismatching timestamps on the .py files. Here's a fragment from a %prep that fixes such a case: # Update timestamps on the files touched by a patch, to avoid non-equal # .pyc/.pyo files across the multilib peers within a build, where "Level" # is the patch prefix option (e.g. -p1) UpdateTimestamps() { Level=$1 PatchFile=$2 # Locate the affected files: for f in $(diffstat $Level -l $PatchFile); do # Set the files to have the same timestamp as that of the patch: touch -r $PatchFile $f done } %patch0 -p1 UpdateTimestamps -p1 %{PATCH0} %patch1 -p1 UpdateTimestamps -p1 %{PATCH1} This assumes you have: BuildRequires: diffstat For some older versions of python 2 (which isn't the case here): if the mtime and contents are identical and the signatures still do not match, check for large numeric constants in the range of 2^32 - 2^64. For each one that is present make sure to append a L to the value to force python2 to treat it as a long. This ensures the same data type is used for both arches. Alternatively, sometimes an arch-specific constant can get embedded in the module (e.g. with autogenerated code).
Seems manual for f in `find %{buildroot}%{_prefix}/share/gcc-%{gcc_version}/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 instead of the %py_byte_compile macro works.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.