Bug 459874 - Review Request: zeromq - Fast messaging system
Review Request: zeromq - Fast messaging system
Status: CLOSED DUPLICATE of bug 603233
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-23 07:02 EDT by Peter Lemenkov
Modified: 2010-06-24 01:26 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-12 01:01:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Lemenkov 2008-08-23 07:02:01 EDT
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.
Comment 1 Jason Tibbitts 2008-09-02 23:42:39 EDT
This package has rpath issues on x86_64:

zeromq.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/zmq_server ['/usr/lib64']
Comment 2 Peter Lemenkov 2008-10-14 09:48:41 EDT
(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
Comment 3 Peter Lemenkov 2008-10-14 09:49:27 EDT
Koji scratch build

http://koji.fedoraproject.org/koji/taskinfo?taskID=880064
Comment 4 R P Herrold 2008-10-14 14:08:23 EDT
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
Comment 5 Peter Lemenkov 2008-10-15 04:55:44 EDT
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+
Comment 6 Jason Tibbitts 2008-11-06 15:48:02 EST
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.
Comment 7 Jason Tibbitts 2008-11-06 22:08:27 EST
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.
Comment 8 Peter Lemenkov 2008-11-16 08:29:12 EST
(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
Comment 9 Jason Tibbitts 2008-11-18 14:00:28 EST
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.
Comment 10 Peter Lemenkov 2008-11-19 10:59:09 EST
(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
Comment 11 Jason Tibbitts 2008-12-01 21:10:45 EST
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.
Comment 12 Peter Lemenkov 2008-12-07 15:54:01 EST
(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
Comment 13 Peter Lemenkov 2008-12-09 08:35:40 EST
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
Comment 14 R P Herrold 2008-12-09 15:21:26 EST
I see you have noted the license change in the .spec file.  Is any other review, occasioned by a relicensing, required?
Comment 15 Peter Lemenkov 2008-12-09 15:57:47 EST
(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@gmail.com> 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
Comment 16 Jason Tibbitts 2008-12-10 14:00:22 EST
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.
Comment 17 Jason Tibbitts 2008-12-10 15:01:46 EST
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.
Comment 18 Jason Tibbitts 2009-03-09 20:05:36 EDT
Any response?
Comment 19 Peter Lemenkov 2009-03-11 07:32:44 EDT
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.
Comment 20 Peter Lemenkov 2009-04-20 04:12:54 EDT
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
Comment 21 Jason Tibbitts 2009-05-16 20:29:03 EDT
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.
Comment 22 Peter Lemenkov 2009-05-17 10:40:32 EDT
I'll try to find why it's failed to build in F-11.
Comment 23 Peter Lemenkov 2009-06-05 04:50:29 EDT
Ver. 0.6.1. is out. I'll post new spec and srpm in this weekend.
Comment 24 Jason Tibbitts 2009-07-11 04:06:05 EDT
Time for my monthly ping.  Did you have any luck with that updated package?
Comment 25 Peter Lemenkov 2009-07-13 13:08:06 EDT
Ver. 1.0.0 is out. I'll update my package in a couple of days (I swear!).
Comment 26 Peter Lemenkov 2009-07-28 08:21:31 EDT
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@GLIBC_2.0
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.
Comment 27 Jason Tibbitts 2009-07-29 14:40:28 EDT
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.
Comment 28 Peter Lemenkov 2009-09-24 09:13:33 EDT
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).
Comment 29 Jason Tibbitts 2009-11-05 18:53:46 EST
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.
Comment 30 Peter Lemenkov 2010-06-12 01:01:07 EDT

*** This bug has been marked as a duplicate of bug 603233 ***

Note You need to log in before you can comment on or make changes to this bug.