Dear Maintainer,

After upgrading libzmq3 to 4.0.4+dfsg-2, the following stops working:

~$ python
cb, [], True)

(waits forever... till  I press CTRL+C)

However, if I downgrade to libzmq3 3.2.3, I can repeat the previous
python lines and the last one returns  immediately without problems as
expected.

This makes me wonder if there shouldn't be a libzmq4 package for the 4.x
series while leaving the libzmq3 for the 3.x series.

Here is what you can find in ZMQ 4 release notes at [1]

"You can now connect to an inproc:// endpoint that does not already exist. See: tests/test_inproc_connect.cpp. NOTE: this is a breaking change in the API. If your application depended on inproc connects failing, you must change it to try to bind instead (a successful bind means there was no previous socket bound to the socket."

As you can guess, Tango depended on inproc connects failing when starting the event system!


So it seems to me that zeromq deserve a libzmq4 and to keep around the libzmq3.
This bug should be RC.

are you ok with this ?


Cheers


Frederic

Hi Frederic,
[...]
 It seems it doesn't use inproc :
path/pytango-8.1.1$ grep -ri inproc *
path/pytango-8.1.1$
 The previous maintainer already uploaded 4.0.4 to unstable, there's
no easy way to get back to 3.x .
 For the moment, no. Will ask Pytango upstream about it.

Laszlo/GCS

Hello László

this is not pytango but the tango library

picca@mordor:~/Debian/main/tango/tango/lib$ grep -ri  inproc
cpp/server/tango_const.h:#define     CTRL_SOCK_ENDPOINT          "inproc://control"
no easy way to get back to 3.x .

Yes usually we end up with this ugly 4.0.4.really.3.2.4 version number.
But this must be discuss with the release team..
or maybe an epoch can help

Cheers

Frederic

 Ah, OK.
 It seems it's not that hard to fix this issue. Please see the
mentioned test file, line 39 [1] which tests the connection first with
bind(). The same can be done in lib/cpp/client/zmqeventconsumer.cpp
with the following patch.
@@ -1170,6 +1170,7 @@ void ZmqEventConsumer::cleanup_EventChan
     try
     {
         zmq::socket_t sender(zmq_context,ZMQ_REQ);
+        sender.bind(CTRL_SOCK_ENDPOINT);
         sender.connect(CTRL_SOCK_ENDPOINT);

 //

As you can see in lib/cpp/client/zmq.hpp line 253, it will throw an
exception making it fail like it would with Zer0MQ 3.x at connect()
time (see the same file, line 260). Needs testing, I hope I can do it
this afternoon.

Kind regards,
Laszlo/GCS
[1] https://github.com/zeromq/libzmq/blob/master/tests/test_inproc_connect.cpp#L39

Hello

I discuss with the tango upstream, Indeed this can fix the problem.
BUT this is a real API breakage from the zeromq3 upstream.

I think that the so number is wrong. instead of
4:0:1 -> libzmq.so.3.1.0

 it should be

4:0:0 -> libzmq.so.4.0.0


here are all the revers dependencies of libzmq3 which could be affected by this
problem. I did not check if the inproc is in use or not.

picca@mordor:~/Debian/main/taurus$ apt-cache rdepends libzmq3
libzmq3
Reverse Depends:
  pushpin

  mongrel2-core

  uwsgi-core

  pypy-zmq

  php5-zmq

  zurl

  tango-test
  tango-starter
  tango-db
  tango-accesscontrol
  libtango8
  libtango-tools

 |ruby-ffi-rzmq

  python3-zmq-dbg
  python3-zmq
  python-zmq-dbg
  python-zmq

  python3-pytango
  python-pytango

  libghc-hbro-contrib-dev
  libghc-hbro-dev
  hbro

  libghc-zeromq3-haskell-dev
  libghc-zeromq4-haskell-dev

AND another major problem is that we do not know about home software already compile against libzmq3...
It was backported ...

So I really think that you should revert to zeromq3 and add a zeromq4 source package.
Convince the zeromq upstream to fix the .so number. zeromq4 deserve its so bump.

I know that this is a problem But I do not see another solution.


Cheers


Frederic

There are other incompatibilities between ZMQ 3 and 4 as well.  The
event messages sent as a result of creating a socket monitor with
zmq_socket_monitor() have a completely different format in the two
versions, and have to be treated differently in code.  (In ZMQ 3 the
message consists of one frame that contains all the information, whereas
in ZMQ 4 it is split into two frames – one for the event ID and payload
value, and one for the endpoint address.)

Any program which uses this feature, and which is compiled against
libzmq3, will break after the upgrade to v4.

Hello, so it seems that upstream agreed on the ABI breakage.

The importance of this bug should be raised, this is now RC.
We should ask the release team how to deal with this mess...
Do you agree with this ?

Cheers


Frederic

(CC'ing the bug)

Well, I think the procedure was already laid out in the bug...
Epoch or a ugly version like 4.x.y+really-3.y.w ...

Another option is to fix all the reverse dependencies, provide patches
and eventually NMU it. (And as eventually the maintainer will want to
upload version 4 someday, one need anyway work with your r-depends to
fix the issues)

IMHO the severity should be raised to critical as it breaks unrelated
software.

IMHO not bumping the so-name is a (upstream) bug here...
https://github.com/zeromq/libzmq/blob/master/configure.ac
indicates that upstream already fixed this:
So a new version packaged (or cherrypicking this change) would help.

Reverse dependencies are anything but unrelated.

Cheers,
Julien

Hello julien, from the point of view of the release team.
What should be do now ?

to my opinion, all we have to do is to upload
zeromq3 with this ugly but necessary +really versionnumber

4.0.3+really-3.2.4-1

then the problem should be fixed once migrated into testing.

is that all ?

thanks for your help

Fred

Hi,

do we realy need a libzmq.so.3 in Jessie? Upstream is preparing a new
stable version now with libzmq.so.4. Given that the breakage between 3
and 4 is minimal (easy to port your software, most just works) do we
need to maintain 2 versions of zeromq?

MfG
	Goswin

Hi,
 Just for the record, we are talking v2 (v2.2.0 to be more precise) to
v4 upgrade and not from a v3 one. Yes, only the Python bindings use v2
in the archive, but supports v4 as well (see compatibility[1]).
I don't know the compatibility level of the C/C++ API between v2 and
v4, but open to discussion if the former should be removed. At least
no other package uses it.
Do you know if upstream supports v2 (important and security fixes) or not?

Regards,
Laszlo/GCS
[1] http://zeromq.org/bindings:python