Hide Forgot
In python3-libs-3.1.2-14.fc14.x86_64, the file: /usr/share/systemtap/tapset/libpython3.1-64.stp has the wrong content. Rather than containing the systemtap python aliases, it appears to be an exact copy of: /usr/share/doc/python3-libs-3.1.2/systemtap-example.stp It looks like python3.spec is using the wrong Source# in the section which is sed-munging the library path. # Systemtap tapset to make it easier to use the systemtap static probes # (actually a template; LIBRARY_PATH will get fixed up during install) # Written by dmalcolm; not yet sent upstream Source5: libpython.stp # Example systemtap script using the tapset # Written by wcohen, mjw, dmalcolm; not yet sent upstream Source6: systemtap-example.stp [...] sed \ -e "s|LIBRARY_PATH|%{_libdir}/%{py_INSTSONAME_optimized}|" \ %{SOURCE6} \ > %{buildroot}%{tapsetdir}/%{libpython_stp_optimized}
Thanks - good catch! Looks like f13 gets it correct, but f14, f15, and master have the bug. Looks like I introduced the bug in: http://pkgs.fedoraproject.org/gitweb/?p=python3.git;a=commit;h=55cf58012d82f965f94163c9e36771b9afe1cda8 when adding the debug build of python3, which had this change that attempted to build the tapset twice, but got the source# wrong: sed \ - -e "s|LIBRARY_PATH|%{_libdir}/%{py_INSTSONAME}|" \ - %{SOURCE5} \ - > %{buildroot}%{tapsetdir}/%{libpython_stp} + -e "s|LIBRARY_PATH|%{_libdir}/%{py_INSTSONAME_optimized}|" \ + %{SOURCE6} \ + > %{buildroot}%{tapsetdir}/%{libpython_stp_optimized} + +sed \ + -e "s|LIBRARY_PATH|%{_libdir}/%{py_INSTSONAME_debug}|" \ + %{SOURCE6} \ + > %{buildroot}%{tapsetdir}/%{libpython_stp_debug} + %endif # with_systemtap
I've fixed these by changing the references to read: %{_sourcedir}/libpython.stp rather than referring to them purely by number. I've pushed fixes to git and am building them as follows: Fedora 14: python3-3.1.2-16.fc14 Git: 4983daa..e956d15 f14/master -> f14/master Building python3-3.1.2-16.fc14 for dist-f14-updates-candidate http://koji.fedoraproject.org/koji/taskinfo?taskID=3011686 Fedora 15: python3-3.2-2.fc15 Git: 607ce95..23be907 f15/master -> f15/master Building python3-3.2-2.fc15 for dist-f15-updates-candidate Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3011698 Fedora 16/"master": python3-3.2-2.fc16 Git: e516bd5..b0ba5d4 master -> master Building python3-3.2-2.fc16 for dist-rawhide Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3011702
(In reply to comment #2) ... > Fedora 14: python3-3.1.2-16.fc14 > Git: 4983daa..e956d15 f14/master -> f14/master > Building python3-3.1.2-16.fc14 for dist-f14-updates-candidate > http://koji.fedoraproject.org/koji/taskinfo?taskID=3011686 Looks like this one got stuck on one of the test cases ("test_threadedtempfile", on the optimized build); so I cancelled it. The other builds ran to completion; closing this out as fixed in rawhide for F16.
(In reply to comment #2) > I've fixed these by changing the references to read: > %{_sourcedir}/libpython.stp > rather than referring to them purely by number. Wouldn't the numbering "more sane" for rpm? See: http://fedoraproject.org/wiki/Packaging:RPM_Source_Dir
Thanks for the link. It took me a while to figure out what that page was getting at. I don't intend to change the specfile to honor that rule. Source file references using numbers is error prone, as proven by this bug (the numbering is different between the python and python3 specfiles). I fully expect that if I tried to follow that rule that I'd introduce more bugs. The rule appears to relate to local builds, rather than Koji builds, and I don't agree with obfuscating the specfile to serve the former use case.
(In reply to comment #5) > Thanks for the link. It took me a while to figure out what that page was > getting at. > > I don't intend to change the specfile to honor that rule. Source file > references using numbers is error prone, as proven by this bug (the numbering > is different between the python and python3 specfiles). I fully expect that if > I tried to follow that rule that I'd introduce more bugs. The rule appears to > relate to local builds, rather than Koji builds, and I don't agree with > obfuscating the specfile to serve the former use case. Without following that rule, I'll expect problems, when changing the name of the sourced libpython.stp, but we'll see ;) Maybe unifying the numbering somehow would be a solution. But that when there are more problems in this direction...
Dave, can we get this pushed out to F15 updates?