I am proposing some changes to the gramps-3.0.4 ebuild because IMO bug 215944 has not been resolved correctly. Let me explain why: Bug 215944 is about precompiled python object files installed under /usr/share. The QA warning was triggered by precompiled python object files generated during compilation phase and then installed afterwards. The "fix" introduced in bug 215944 disables python object files compilation during compilation phase and uses python.eclass's python_mod_optimize function which is good but... Since all python scripts are still installed under /usr/share, .py[co] files are again generated under /usr/share! The only "improvement" is that portage does not throw a QA warning because they are slipped past portage. IMO, .py[co] files belong under /usr/$(get_libdir)/python${PYVER}/site-packages (which is identical to $(python_get_sitedir)). The modification to the ebuild, I will attach, will comply with this. Second,I suggest to add a check to python.eclass to python_mod_{optimize,compile) to throw a QA warning because portage will not catch .py[co] files in /usr/share because they are generated after installation phase. BR, Dustin Reproducible: Always
Created attachment 185176 [details, diff] Install .py[co] files under $(python_get_sitedir)/${PN}
(In reply to comment #0) > Since all python scripts are still installed under /usr/share, .py[co] files > are again generated under /usr/share! The only "improvement" is that portage > does not throw a QA warning because they are slipped past portage. Ok, I will have a deeper look at your patch and will apply it soonish. > Second,I suggest to add a check to python.eclass to > python_mod_{optimize,compile) to throw a QA warning because portage will not > catch .py[co] files in /usr/share because they are generated after installation > phase. This is not in our scope...please open another bug report with that issue, as Python team should handle that.
I just checked my Gramps 3.1.1 installation and noticed no py[c,o] files at all. So I assume that 3.0.4 workaround is not needed anymore, or do I get something wrong. I want to stabilise 3.1.1 soon, so 3.0.4 will phase out eventually.
(In reply to comment #3) > I just checked my Gramps 3.1.1 installation and noticed no py[c,o] files at > all. So I assume that 3.0.4 workaround is not needed anymore, or do I get > something wrong. I want to stabilise 3.1.1 soon, so 3.0.4 will phase out > eventually. Everything backwards! Yes, they are still there...let me play with your patch a bit before I commit it to the tree.
Technically this is a dupe of bug 215944, but that would have been unfair regarding your contribution. Thank you for providing this fix, it is applied in 3.1.1 (I won't touch 3.0.4 anymore) and will go stable as soon as possible. Closing this bug.
This has been reported upstream...see URL.
(In reply to comment #6) > This has been reported upstream...see URL. After some arguing (in a civil manner), Gramps' upstream agreed to work on the issue for 3.2. For the time being we will fix it in the ebuild.
