https://bugzilla.redhat.com/show_bug.cgi?id=717748
--- Comment #12 from Scott Tsai <scottt.tw(a)gmail.com> ---
(In reply to comment #11)
Yannick,
After your libtoolize change I can now build the packages successfully.
I suspect you didn't see the failture from comment #9 before because you were
using rpmbuild locally and you already have a copy of the lttng-ust libraries
in /usr/lib6{,64}. (Having the libraries in the default linker search path is
equivalent to helping ld find them via -rpath-link.)
Comments on the .spec file follows:
1. License should be "LGPLv2 and GPLv2"
liblttng-ust-ctl/ustctl.c is GPLv2 only and is used to build
liblttng-ust-ctl.so. ust-ctl.h is also GPLv2 only and shipped in the -devel
package.
The assertion in the COPYING file that ustctl.c is only used by lttng-sessiond
is not true when we ship it in a library with a public header.
BTW, lttng-ust being LGPLv2 only precludes using it with
the {,L}LGPLv3 libraries from Samba, which is unfortunate.
2. BuildRequires userspace-rcu-devel >= 0.6.6
-BuildRequires: pkgconfig libuuid-devel userspace-rcu-devel texinfo gcc-c++
systemtap-sdt-devel
+BuildRequires: libuuid-devel texinfo systemtap-sdt-devel
+BuildRequires: userspace-rcu-devel >= 0.6.6
lttng-ust's configure.ac wants userspace-rcu >= 0.6.6 and
since the older userspace-rcu-0.4.1 has been in Fedora since Feb 2011
having this versioned build requires is easier for users rebuilding this RPM
locally.
Remove gcc-c++ from BuildRequires per
https://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2.
Also remove pkgconfig from BuildRequires since it's not actually used in the
build process.
Note that installing lttng-ust.pc doesn't require pkgconfig. The pkgconfig
related depencies in -devel would still be automatically picked up by rpmbuild.
3. Unless you're targetting EPEL5, remove the BuildRoot tag, the %clean section
and the second %defattr() in the %files -n %{name}-devel section.
Per
https://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag:
-BuildRoot: %{_tmppath}/%{name}-%{version}-build
-%clean
-rm -rf %buildroot
%files -n %{name}-devel
-%defattr(-,root,root)
%{_bindir}/lttng-gen-tp
The last point in particular is mostly to make the fedora-review tool happy.
4. ExclusiveArch and arm
From a quick reading of configure.ac and the git logs, I believe
lttng-ust does
support the ARM architecture. I recommend just removing the
ExclusiveArch line
unless you have a good reason.
5. I recommend adding a comment in the .spec on why "--with-java-jdk" isn't
enabled:
%configure --docdir=%{_docdir}/%{name} --disable-static --with-sdt
+# --with-java-jdk
+# Java support was disabled in lttng-ust's stable-2.0 branch upstream in
+#
http://git.lttng.org/?p=lttng-ust.git;a=commit;h=655a0d112540df3001f9823c...
+# We can revisit enabling this when the next major version is released.
+
make %{?_smp_mflags} V=1
6. Use quotes consistently for %buildroot like other RPM directory name macros
%install
-make DESTDIR=%buildroot install
-rm -vf %buildroot%{_libdir}/*.la
+make DESTDIR=%{buildroot} install
+rm -vf %{buildroot}%{_libdir}/*.la
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
7. Upstream recently released lttng-ust-2.0.4
I looked at the git log and suspect we'd want to pick up the various deadlock
fixes.
I'll approve this review once the above points are addressed.
On a separate note, while performing this reivew I tried to run the code in the
tests/ directory (the few that were not disabled upstream) and the example
shipped as documentation. But since we don't lttng-tools and the log viewers
packaged, I was only able to verify that the sample and test programs can be
built and run but can't actually see the traces.
Do you intend to package lttng-tools nad the log viewers?
--
You are receiving this mail because:
You are on the CC list for the bug.