Spec URL: http://peter.fedorapeople.org/zeromq.spec SRPM URL: http://peter.fedorapeople.org/zeromq-0.3-1.fc9.src.rpm Description: Fast messaging system.
This package has rpath issues on x86_64: zeromq.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/zmq_server ['/usr/lib64']
(In reply to comment #1) > This package has rpath issues on x86_64: > > zeromq.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/zmq_server > ['/usr/lib64'] Fixed upstream. New version 0.3.2 http://peter.fedorapeople.org/zeromq.spec http://peter.fedorapeople.org/zeromq-0.3.2-1.fc9.src.rpm
Koji scratch build http://koji.fedoraproject.org/koji/taskinfo?taskID=880064
Is the license entry correct? I see at: http://www.zeromq.org/start * October, 8th, 2008: ØMQ is LGPL'd from now on! LGPL version is available in the form of source code in Subversion at the moment. LGPL'd package is coming soon. but the spec file has: License: GPLv3+ -- Russ herrold
Yes,(In reply to comment #4) > Is the license entry correct? Yes. Although they mentioned about re-licensing ZeroMQ, this was made only for trunk (and therefore for future releases). This release, 0.3.2, is still under GPLv3+
Just built this again. rpmlint says: zeromq.src: W: mixed-use-of-spaces-and-tabs (spaces: line 5, tab: line 1) Not a big deal; fix it if you like. zeromq-c.x86_64: W: no-documentation zeromq-c-devel.x86_64: W: no-documentation Not a problem. zeromq.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libzmq.so.0.0.0 /lib64/libm.so.6 zeromq-c.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libczmq.so.0.0.0 /lib64/libpthread.so.0 zeromq-c.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libczmq.so.0.0.0 /lib64/libm.so.6 These are linked against libm and libpthread without actually calling any functions in those libraries. I don't think this is a problem as it doesn't cause any additional dependencies, although it should go away if you can get -Wl,as-needed passed to the compiler during the link stage. Since this package uses libtool, the trick at https://fedoraproject.org/wiki/PackageMaintainers/Common_Rpmlint_Issues#unused-direct-shlib-dependency may be useful. I'll take a better look when I get home.
I note that 0.3.2 isn't announced upstream, just 0.3.1. 0.3.3 seems to be tagged as well but I didn't see a tarball. The descriptions really need some elaboration. "Development files for C", for example, is almost completely nondescriptive, and "Fast messaging system", while fine for a summary, really needs elaboration because it could refer just as well to mutt or an IRC client. Unfortunately the upstream web site is completely useless as a source of descriptive text. Maybe: ZeroMQ (0MQ) is an implementation of the Advanced Message Queuing Protocol (AMQP) written in C++, calling itself "the fastest messaging system ever”. And then something like: ZeroMQ C interface libaries. or something for the C subpackage and Development files for the ZeroMQ C interface libraries. Is there any reason the python and java interfaces aren't built? And if the python interface isn't being built, why is there a build dependency on python-devel? Maybe I'm missing something, but zeromq-c-devel doesn't seem to have any dependency on zeromq-devel, which leaves /usr/include/zmq unowned if zeromq-c-devel only is installed. Do you know if the tests under the perf directory are runnable at build time? It seems like there are some local tests, but I have no idea how to run them. * source files match upstream: d11291730967f91762bfdbf7352871ba20fddffe8eead1a66e96cd1053f47eab zmq-0.3.2.tar.gz * package meets naming and versioning guidelines. * specfile is properly named, is cleanly written and uses macros consistently. X summaries could use some work. X descriptions could use some work. * dist tag is present. * build root is OK. * license field matches the actual license. * license is open source-compatible. * license text included in package. * latest version is being packaged. ? not sure about BuildRequires: python-devel. * compiler flags are appropriate. * %clean is present. * package builds in mock (rawhide, x86_64). * package installs properly. * debuginfo package looks complete. X rpmlint has some easily fixed complaints. X final provides and requires: zeromq-0.3.2-1.fc10.x86_64.rpm libzmq.so.0()(64bit) zeromq = 0.3.2-1.fc10 zeromq(x86-64) = 0.3.2-1.fc10 = /sbin/ldconfig libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(GLIBCXX_3.4)(64bit) libzmq.so.0()(64bit) zeromq-c-0.3.2-1.fc10.x86_64.rpm libczmq.so.0()(64bit) zeromq-c = 0.3.2-1.fc10 zeromq-c(x86-64) = 0.3.2-1.fc10 = /sbin/ldconfig libczmq.so.0()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(GLIBCXX_3.4)(64bit) libzmq.so.0()(64bit) zeromq = 0.3.2-1.fc10 X no dependency on zeromq-devel zeromq-c-devel-0.3.2-1.fc10.x86_64.rpm zeromq-c-devel = 0.3.2-1.fc10 zeromq-c-devel(x86-64) = 0.3.2-1.fc10 = libczmq.so.0()(64bit) zeromq-c = 0.3.2-1.fc10 zeromq-devel-0.3.2-1.fc10.x86_64.rpm zeromq-devel = 0.3.2-1.fc10 zeromq-devel(x86-64) = 0.3.2-1.fc10 = libzmq.so.0()(64bit) zeromq = 0.3.2-1.fc10 ? not sure if there's a test suite there or not. * shared libraries installed: ldconfig is called where necessary unversioned .so files are present in the respective -devel packages. X /usr/include/zmq ownership issues in zeromq-c-devel. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * no generically named files * scriptlets are OK (ldconfig) * code, not content. * documentation is small, so no -doc subpackage is necessary. * %docs are not necessary for the proper functioning of the package. * headers are in the -devel packages. * no pkgconfig files. * no static libraries. * no libtool .la files.
(In reply to comment #7) > I note that 0.3.2 isn't announced upstream, just 0.3.1. 0.3.3 seems to be > tagged as well but I didn't see a tarball. Developers of ZeroMQ created version 0.3.3 specially for Fedora, to meet Fedora's policy regirding -rpath. It wasn't publically announced. > The descriptions really need some elaboration. "Development files for C", for > example, is almost completely nondescriptive, and "Fast messaging system", > while fine for a summary, really needs elaboration because it could refer just > as well to mutt or an IRC client. Unfortunately the upstream web site is > completely useless as a source of descriptive text. Maybe: > ZeroMQ (0MQ) is an implementation of the Advanced Message Queuing Protocol > (AMQP) written in C++, calling itself "the fastest messaging system ever”. > And then something like: > ZeroMQ C interface libaries. > or something for the C subpackage and > Development files for the ZeroMQ C interface libraries. Changed a little. > Is there any reason the python and java interfaces aren't built? And if the > python interface isn't being built, why is there a build dependency on > python-devel? Python installation was broken (patch submitted upstream where it was accepted). I fixed it and re-enabled. However I'm not sure about correct installation of java-interface, because I'm not keen in java stuff. > Maybe I'm missing something, but zeromq-c-devel doesn't seem to have any > dependency on zeromq-devel, which leaves /usr/include/zmq unowned if > zeromq-c-devel only is installed. Good catch - it was my fault. Fixed. > Do you know if the tests under the perf directory are runnable at build time? > It seems like there are some local tests, but I have no idea how to run them. I'll investigate it. > * source files match upstream: > d11291730967f91762bfdbf7352871ba20fddffe8eead1a66e96cd1053f47eab > zmq-0.3.2.tar.gz > * package meets naming and versioning guidelines. > * specfile is properly named, is cleanly written and uses macros consistently. > X summaries could use some work. > X descriptions could use some work. Added more descriptive texts. > * dist tag is present. > * build root is OK. > * license field matches the actual license. > * license is open source-compatible. > * license text included in package. > * latest version is being packaged. > ? not sure about BuildRequires: python-devel. Re-enabled python-interface (requires autoreconf summoning). > * compiler flags are appropriate. > * %clean is present. > * package builds in mock (rawhide, x86_64). > * package installs properly. > * debuginfo package looks complete. > X rpmlint has some easily fixed complaints. Cosmetic fixes made. However situation with unused dependencies on x86_64 will be investigated later (no access to x64 right now). > X final provides and requires: > zeromq-0.3.2-1.fc10.x86_64.rpm > libzmq.so.0()(64bit) > zeromq = 0.3.2-1.fc10 > zeromq(x86-64) = 0.3.2-1.fc10 > = > /sbin/ldconfig > libgcc_s.so.1()(64bit) > libgcc_s.so.1(GCC_3.0)(64bit) > libstdc++.so.6()(64bit) > libstdc++.so.6(CXXABI_1.3)(64bit) > libstdc++.so.6(GLIBCXX_3.4)(64bit) > libzmq.so.0()(64bit) > > zeromq-c-0.3.2-1.fc10.x86_64.rpm > libczmq.so.0()(64bit) > zeromq-c = 0.3.2-1.fc10 > zeromq-c(x86-64) = 0.3.2-1.fc10 > = > /sbin/ldconfig > libczmq.so.0()(64bit) > libgcc_s.so.1()(64bit) > libgcc_s.so.1(GCC_3.0)(64bit) > libstdc++.so.6()(64bit) > libstdc++.so.6(CXXABI_1.3)(64bit) > libstdc++.so.6(GLIBCXX_3.4)(64bit) > libzmq.so.0()(64bit) > zeromq = 0.3.2-1.fc10 > X no dependency on zeromq-devel Added. > zeromq-c-devel-0.3.2-1.fc10.x86_64.rpm > zeromq-c-devel = 0.3.2-1.fc10 > zeromq-c-devel(x86-64) = 0.3.2-1.fc10 > = > libczmq.so.0()(64bit) > zeromq-c = 0.3.2-1.fc10 > > zeromq-devel-0.3.2-1.fc10.x86_64.rpm > zeromq-devel = 0.3.2-1.fc10 > zeromq-devel(x86-64) = 0.3.2-1.fc10 > = > libzmq.so.0()(64bit) > zeromq = 0.3.2-1.fc10 > > ? not sure if there's a test suite there or not. AFAIK, nope. > * shared libraries installed: > ldconfig is called where necessary > unversioned .so files are present in the respective -devel packages. > X /usr/include/zmq ownership issues in zeromq-c-devel. Fixed. > * doesn't own any directories it shouldn't. > * no duplicates in %files. > * file permissions are appropriate. > * no generically named files > * scriptlets are OK (ldconfig) > * code, not content. > * documentation is small, so no -doc subpackage is necessary. > * %docs are not necessary for the proper functioning of the package. > * headers are in the -devel packages. > * no pkgconfig files. > * no static libraries. > * no libtool .la files. http://peter.fedorapeople.org/zeromq.spec http://peter.fedorapeople.org/zeromq-0.3.2-2.fc9.src.rpm
This fails to build; autoreconf is called without any build dependency on the autotools. Some people insist that autotools should never be called as part of a package build; I'm not one of them, but it seems a waste for that one line change. Do you know how much change there is in the resulting Makefile? Maybe you could just patch that instead. Or, I guess, fix the build dependency. The descriptive texts are better now; the only notes I'd make are s/standarts/standards/ in the main package %description and terminate %description lines with periods.
(In reply to comment #9) > This fails to build; autoreconf is called without any build dependency on the > autotools. Some people insist that autotools should never be called as part of > a package build; I'm not one of them, but it seems a waste for that one line > change. Do you know how much change there is in the resulting Makefile? Maybe > you could just patch that instead. Or, I guess, fix the build dependency. Added autoconf as a BiuldRequires. I don't want to fix makefile instead of rebuilding it, because my patch already accepted upstream. Next release (0.4 - scheduled on next week) will include this fix. > The descriptive texts are better now; the only notes I'd make are > s/standarts/standards/ in the main package %description and terminate > %description lines with periods. Done. http://peter.fedorapeople.org/zeromq.spec http://peter.fedorapeople.org/zeromq-0.3.2-3.fc9.src.rpm
Sorry for the delay; the US holiday season is upon us. Unfortunately this still doesn't build, because you don't pull in automake, leading to the completely cryptic: + autoreconf -f Can't exec "aclocal": Permission denied at /usr/share/autoconf/Autom4te/FileUtils.pm line 326. Adding automake gets me to: + autoreconf -f configure.in:15: error: possibly undefined macro: AC_PROG_LIBTOOL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. So I added libtool and it gets down to: ./configure: line 16530: syntax error near unexpected token `SDL,' ./configure: line 16530: ` PKG_CHECK_MODULES(SDL, sdl)' Now, I have no idea why sdl might be required to build this, but I suspect that your comment "# Needed for camera example" might be related, since you're rebuilding the autoconf stuff for that example even if you're not actually building it. I added SDL-devel and it gets further: checking for jni.h in a /usr/lib64/jvm/java-1.6.0-openjdk/include dir... configure: error: Could not find jni.h in /usr/lib64/jvm/java-1.6.0-openjdk/include directory. So --with-java needs java-1.6.0-openjdk-devel in order to build, but mock pulls in java-1.5.0-gcj-devel because both provide java-devel. I don't know quite enough about java to understand this.
(In reply to comment #11) * I added necessary BR (and SDL-devel as a temporary solution). * Also correct java-related BR were added. http://peter.fedorapeople.org/zeromq.spec http://peter.fedorapeople.org/zeromq-0.3.2-4.fc10.src.rpm Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=985877
Ver. 0.4 is out! http://peter.fedorapeople.org/zeromq.spec http://peter.fedorapeople.org/zeromq-0.4-1.fc10.src.rpm Dropped all workarounds, mentioned above. Koji scratchbuild: http://koji.fedoraproject.org/koji/taskinfo?taskID=988972
I see you have noted the license change in the .spec file. Is any other review, occasioned by a relicensing, required?
(In reply to comment #14) > I see you have noted the license change in the .spec file. Is any other > review, occasioned by a relicensing, required? Actually, I forgot to note in my previous comment, that upstream relicensed project under LGPLv3 or any later version. Thanks for pointing on this. I don't think that some extra review required in that case. Ver. 0.4-2 %changelog * Tue Dec 9 2008 Peter Lemenkov <lemenkov> 0.4-2 - Changed summary. - Fixed license field. http://peter.fedorapeople.org/zeromq.spec http://peter.fedorapeople.org/zeromq-0.4-2.fc10.src.rpm
OK, this does indeed build, even on rawhide. (The package in comment #12 failed there due to a libtool issue, but built fine on F10.) Since the license changed, I have re-checked it. The source in the "examples" directory is GPLv3+, not LGPLv3+, but the examples aren't built and so aren't present in the final package. All of the other source is indeed LGPLv3+, but I note a bug that needs to be reported upstream: In libpyzmq/pyzmq.cpp, you see "static const char* pyZMQ_doc" which has, at the end: "0MQ is distributed under GNU General Public License v3\n"; which seems to conflict with reality. I don't think this is a problem for this pachage, however. It seems to me that the issues I had are fixed; there are two new thing that I need to look at: zeromq-python.x86_64: W: devel-file-in-non-devel-package /usr/lib64/python2.6/site-packages/libpyzmq.so zeromq-java.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libjzmq.so Both of these have regular versioned .so* files alongside unversioned ones, and I don't know all of the rules for these so I will ask. Hopefully this will be done soon.
I talked to a Java expert who noted the following: http://www.zeromq.org/code:jzmq indicates that a class file should also be installed, but you have to do it manually. The Java guidelines indicate that JNI libraries should be installed in a subdirectorty under _libdir. http://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI Honestly the java stuff exposes several issues that I don't fully understand. I would suggest that you talk to a java expert; #fedora-java on IRC should be able to help far better than I can. With regards to the python module, my understanding is the following: It is pointless to version the library. Just install a .so file. It should not be named with the "lib" prefix, as that would mean you use it with "import libpyzmq" instead of "import pyzmq" as documented at http://www.zeromq.org/code:pyzmq.
Any response?
Updated to latest version 0.5 (they added AMQP compatibility and SCTP support). http://peter.fedorapeople.org/zeromq.spec http://peter.fedorapeople.org/zeromq-0.5-1.fc10.src.rpm The issues with python and java libraries still not resolved - I'll try to address these issues in a couple of days.
Updated to latest version 0.6 (java-plugin disabled since its installation is broken). http://peter.fedorapeople.org/zeromq.spec http://peter.fedorapeople.org/zeromq-0.6-1.fc10.src.rpm
This one fails to build for me in current F11; I get a bunch of errors like: ./zmq/atomic_ptr.hpp:114:6: error: #elif with no expression ./zmq/atomic_ptr.hpp:154:6: error: #elif with no expression in several different files. A failing scratch build is at http://koji.fedoraproject.org/koji/taskinfo?taskID=1358350 An F10 build succeeds. I can review it if you can't figure out what's breaking on F11, but it seems pointless to import a package that won't build on our new release.
I'll try to find why it's failed to build in F-11.
Ver. 0.6.1. is out. I'll post new spec and srpm in this weekend.
Time for my monthly ping. Did you have any luck with that updated package?
Ver. 1.0.0 is out. I'll update my package in a couple of days (I swear!).
Ver. 1.0.0 is out (java plugin still disabled, as well as new plugins for Ruby and .Net/Mono) http://peter.fedorapeople.org/zeromq.spec http://peter.fedorapeople.org/zeromq-1.0.0-1.fc11.src.rpm Koji scratchbuild for EL-5: http://koji.fedoraproject.org/koji/taskinfo?taskID=1550083 Koji scratchbuild for F-11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1550090 rpmlint output: [petro@Sulaco SPECS]$ rpmlint ../RPMS/ppc/zeromq-* zeromq.ppc: W: shared-lib-calls-exit /usr/lib/libzmq.so.1.0.0 exit zeromq-c.ppc: W: no-documentation zeromq-python.ppc: W: no-documentation 7 packages and 0 specfiles checked; 0 errors, 3 warnings. [petro@Sulaco SPECS]$ I'll send a note upstream regarding "shared-lib-calls-exit" message. Other two warnings may be safely ignored, since these two subpackages really don't have any documentation so far.
Note also the three rpmlint complaints you missed (the same as in comment #6): zeromq.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libzmq.so.1.0.0 /lib64/libm.so.6 zeromq-c.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libczmq.so.1.0.0 /usr/lib64/libsctp.so.1 zeromq-c.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libczmq.so.1.0.0 /lib64/libm.so.6 The libsctp one is interesting because that package contains only libczmq and thus would seem to have no need to depend on libsctp. It only does because it's linked against libsctp even though it doesn't call anything there. Did you investigate the -Wl,as-needed thing I suggested? http://fedoraproject.org/wiki/Common_Rpmlint_issues#unused-direct-shlib-dependency I'd say that except for that everything's done.
Ver. 1.0.1 http://peter.fedorapeople.org/zeromq.spec http://peter.fedorapeople.org/zeromq-1.0.1-1.fc11.src.rpm The upstream introduced Tcl, Lua and Ruby bindings. Unfortunately, the "make install" target for these bindings is broken. I'll plan to fix these issues (as well as issue with unused-direct-shlib-dependency) in the nearest future (this weekend or next week, if time permits).
I wasn't sure if I should wait for those fixes, but it's been several weeks. I can verify that 1.0.1-1 builds fine and has only the unused-direct-shlib-dependency issues listed in comment 27. I do think the libsctp one is worth a fix if possible, but in the end zeromq-c depends on zeromq which depends on libsctp so it actually makes no difference to the dependency chain. Just let me know what you'd like to do.
*** This bug has been marked as a duplicate of bug 603233 ***