Hi, great work!
I noticed the zeromq.org download page http://zeromq.org/intro:get-the-software hasn't been updated yet. I also found out that the 4.2.0 release was tagged in libzmq repository instead of zeromq4-2 fork. Does it means that zeromq project is moving away from fork model for releases? Or it's just for a zero release? Bye Michal On Sat, Nov 5, 2016 at 8:44 AM, Luca Boccassi <[email protected]> wrote: > Final status update: > > CZMQ 4.0.0 is out, announcement has been sent: > > https://github.com/zeromq/czmq/releases/tag/v4.0.0 > > What a ride :-) > > libzmq 4.2.0 has been already uploaded to Debian (Thanks László for the > very quick upload!), now I hope I can get CZMQ 4.0.0 up too by tomorrow. > > On Fri, 2016-11-04 at 13:35 +0000, Luca Boccassi wrote: >> Status update: >> >> CZMQ release notes PR is open: >> >> https://github.com/zeromq/czmq/pull/1542 >> >> I will be travelling now until the evening (might have some time at >> airport), so if you have anything to add please merge and send a new >> PR :-) >> I would like to release v4.0.0 tonight, so that I can (barely!) make it >> for Debian 9 transition freeze. Phew! >> >> On Fri, 2016-11-04 at 10:46 +0000, Luca Boccassi wrote: >> > Status update: >> > >> > libzmq 4.2.0 is out! Email sent to the announce list. >> > >> > https://github.com/zeromq/libzmq/releases/tag/v4.2.0 >> > >> > CZMQ is next! >> > >> > On Fri, 2016-11-04 at 09:52 +0000, Luca Boccassi wrote: >> > > Status update: >> > > >> > > Added missing CTX option to CZMQ, retired more deprecated methods that >> > > are in STABLE classes. >> > > >> > > Fixed a few typos in the rel notes (thanks Himikof and Paddor!), still >> > > waiting for someone to merge: >> > > >> > > https://github.com/zeromq/libzmq/pull/2189 >> > > >> > > >> > > On 3 November 2016 at 09:34, Luca Boccassi <[email protected]> >> > > wrote: >> > > > Status update: >> > > > >> > > > I've added all the missing options to CZMQ (check please!), and I >> > > > prepared >> > > > the release notes for libzmq 4.2, waiting for a merge: >> > > > >> > > > https://github.com/zeromq/libzmq/pull/2189 >> > > > >> > > > Anything else we should mention? >> > > > >> > > > >> > > > On Nov 1, 2016 21:33, "Luca Boccassi" <[email protected]> wrote: >> > > >> >> > > >> Status update: >> > > >> >> > > >> libzmq 4.1.6, libzmq 4.2.0-rc1 and czmq 4.0.0-rc1 are out on Github: >> > > >> >> > > >> https://github.com/zeromq/zeromq4-1/releases/tag/v4.1.6 >> > > >> https://github.com/zeromq/libzmq/releases/tag/v4.2.0-rc1 >> > > >> https://github.com/zeromq/czmq/releases/tag/v4.0.0-rc1 >> > > >> >> > > >> I'll send an email to the announce list shortly. As I wrote earlier >> > > >> I'll work to have proper release notes for the stable releases. >> > > >> >> > > >> Unless there are any objections, I'm aiming to push libzmq 4.2.0 >> > > >> stable tomorrow by the end of the day, and czmq the day after. >> > > >> >> > > >> It's an aggressive schedule, but I would _really_ like to get CZMQ >> > > >> 4.0.0 in Debian and the transition freeze date is Saturday (ABI/API is >> > > >> borken so there needs to be a transition), and for that I need libzmq >> > > >> up before it. >> > > >> >> > > >> Any objections? >> > > >> >> > > >> I've also noticed that not all the libzmq socket options are available >> > > >> in CZMQ, so this gives me some time to fix that. >> > > >> >> > > >> >> > > >> On 1 November 2016 at 14:48, Doron Somech <[email protected]> wrote: >> > > >> > Great news! >> > > >> > >> > > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi >> > > >> > <[email protected]> >> > > >> > wrote: >> > > >> >> >> > > >> >> Status update: >> > > >> >> >> > > >> >> - v2 APIs are gone from CZMQ: >> > > >> >> https://github.com/zeromq/czmq/pull/1531 >> > > >> >> https://github.com/zeromq/czmq/pull/1532 >> > > >> >> - PR is out to bump the libtool version and changelog for libzmq: >> > > >> >> https://github.com/zeromq/libzmq/pull/2184 >> > > >> >> - PR is out to backport the zmq_msg_t fix to 4.1: >> > > >> >> https://github.com/zeromq/zeromq4-1/pull/155 >> > > >> >> >> > > >> >> Once it's all merged I will tag 4.2.0~rc1 first, then release 4.1.6 >> > > >> >> from >> > > >> >> zeromq4-1 since quite a few fixes have accumulated. Then I'll send >> > > >> >> PRs >> > > >> >> to prepare for CZMQ 4.0.0~rc1. >> > > >> >> >> > > >> >> After the RCs are out, I'll work on the changelogs/NEWS files >> > > >> >> (help is >> > > >> >> appreciated!) as they have fallen dramatically behind. >> > > >> >> >> > > >> >> I'll also prepare more formal release notes for the stable rels, >> > > >> >> the >> > > >> >> RCs >> > > >> >> will have just a quick note since they are RCs. >> > > >> >> >> > > >> >> On Mon, 2016-10-31 at 23:47 +0000, Luca Boccassi wrote: >> > > >> >> > Cool! >> > > >> >> > >> > > >> >> > I can take care of it if you like. Tentative plan: >> > > >> >> > >> > > >> >> > Tomorrow push an RC1 for libzmq, then the pr to CZMQ to retire v2 >> > > >> >> > APIs, >> > > >> >> > then the RC1 for CZMQ. >> > > >> >> > >> > > >> >> > If it's all good then a couple days later the finals. I would >> > > >> >> > really >> > > >> >> > like >> > > >> >> > to make it for the debian 9 transition freeze which is Saturday. >> > > >> >> > >> > > >> >> > On Oct 31, 2016 22:23, "Doron Somech" <[email protected]> wrote: >> > > >> >> > >> > > >> >> > > Sorry, yes, lets do it :) >> > > >> >> > > >> > > >> >> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" >> > > >> >> > > <[email protected]> >> > > >> >> > > wrote: >> > > >> >> > > >> > > >> >> > >> Ping :-) >> > > >> >> > >> >> > > >> >> > >> On Oct 28, 2016 18:48, "Luca Boccassi" >> > > >> >> > >> <[email protected]> >> > > >> >> > >> wrote: >> > > >> >> > >> >> > > >> >> > >>> I have sent a solution for the alignment problem that solves >> > > >> >> > >>> the >> > > >> >> > >>> sigbus >> > > >> >> > >>> problem without breaking ABI compat (plus follow-up for VC++ >> > > >> >> > >>> - >> > > >> >> > >>> sorry >> > > >> >> > >>> Windows guys https://github.com/zeromq/libzmq/pull/2179 ). >> > > >> >> > >>> >> > > >> >> > >>> I tested the alignment and sigbus problem on x86_64 by >> > > >> >> > >>> enabling >> > > >> >> > >>> alignment check with: >> > > >> >> > >>> >> > > >> >> > >>> __asm__("pushf\norl $0x40000,(%rsp)\npopf"); >> > > >> >> > >>> >> > > >> >> > >>> All was fine. >> > > >> >> > >>> >> > > >> >> > >>> I ran tests built from the zeromq4-1 repository against a >> > > >> >> > >>> shared >> > > >> >> > >>> lib >> > > >> >> > >>> from the head of libzmq repo, and they all run fine minus the >> > > >> >> > >>> ZMQ_REQ_CORRELATE one but that option was borken anyway. >> > > >> >> > >>> >> > > >> >> > >>> This allows us to do a release now, and then when we are >> > > >> >> > >>> ready we >> > > >> >> > >>> can do >> > > >> >> > >>> the ABI breakage, without blocking 4.2. Which is nice since >> > > >> >> > >>> it >> > > >> >> > >>> means >> > > >> >> > >>> it >> > > >> >> > >>> might make it for Debian 9! >> > > >> >> > >>> >> > > >> >> > >>> So, Doron et al, shall we do the bump this weekend? >> > > >> >> > >>> >> > > >> >> > >>> On Thu, 2016-10-20 at 17:12 -0500, Thomas Rodgers wrote: >> > > >> >> > >>> > I will have some time most likely the week of Nov6 (off >> > > >> >> > >>> > for a >> > > >> >> > >>> > week >> > > >> >> > >>> > of >> > > >> >> > >>> C++ >> > > >> >> > >>> > Committee 'fun') to test different message size >> > > >> >> > >>> > alternatives. >> > > >> >> > >>> > I'll >> > > >> >> > >>> follow >> > > >> >> > >>> > up with my results here for consideration the next time we >> > > >> >> > >>> > are >> > > >> >> > >>> inclined to >> > > >> >> > >>> > break the ABI compatibility :) >> > > >> >> > >>> > >> > > >> >> > >>> > On Sunday, October 16, 2016, Brian Knox >> > > >> >> > >>> > <[email protected]> >> > > >> >> > >>> wrote: >> > > >> >> > >>> > >> > > >> >> > >>> > > A new stable version would definitely help me in my >> > > >> >> > >>> > > quest to >> > > >> >> > >>> > > get >> > > >> >> > >>> ZeroMQ >> > > >> >> > >>> > > support enabled by default in rsyslog in distros. >> > > >> >> > >>> > > >> > > >> >> > >>> > > On Sun, Oct 16, 2016 at 2:40 PM Doron Somech >> > > >> >> > >>> > > <[email protected]> >> > > >> >> > >>> wrote: >> > > >> >> > >>> > > >> > > >> >> > >>> > >> I say lets bump. >> > > >> >> > >>> > >> >> > > >> >> > >>> > >> On Oct 15, 2016 20:32, "Luca Boccassi" >> > > >> >> > >>> > >> <[email protected]> >> > > >> >> > >>> wrote: >> > > >> >> > >>> > >> >> > > >> >> > >>> > >>> As Thomas said, false sharing would be a real issue >> > > >> >> > >>> > >>> with >> > > >> >> > >>> > >>> 96. >> > > >> >> > >>> > >>> >> > > >> >> > >>> > >>> So given a release is long due, at this point I'd say >> > > >> >> > >>> > >>> to >> > > >> >> > >>> > >>> drop >> > > >> >> > >>> > >>> this >> > > >> >> > >>> for >> > > >> >> > >>> > >>> the moment. >> > > >> >> > >>> > >>> >> > > >> >> > >>> > >>> What do we do for the change to union for zmq_msg_t? >> > > >> >> > >>> > >>> Bump >> > > >> >> > >>> > >>> ABI >> > > >> >> > >>> version or >> > > >> >> > >>> > >>> not? >> > > >> >> > >>> > >>> >> > > >> >> > >>> > >>> On Thu, 2016-10-06 at 09:53 +0300, Doron Somech wrote: >> > > >> >> > >>> > >>> > No new socket type, I worked at the time on binary >> > > >> >> > >>> > >>> > message >> > > >> >> > >>> > >>> > type, >> > > >> >> > >>> might >> > > >> >> > >>> > >>> > complete it sometime, but it is not urgent. >> > > >> >> > >>> > >>> > >> > > >> >> > >>> > >>> > If there is a lot of performance penalty we can give >> > > >> >> > >>> > >>> > it >> > > >> >> > >>> > >>> > up, >> > > >> >> > >>> > >>> > I >> > > >> >> > >>> will >> > > >> >> > >>> > >>> > find another solution for the Radio-Dish. >> > > >> >> > >>> > >>> > >> > > >> >> > >>> > >>> > What about 96 bytes? same penalty? >> > > >> >> > >>> > >>> > >> > > >> >> > >>> > >>> > Regarding the binding, I'm not sure. >> > > >> >> > >>> > >>> > >> > > >> >> > >>> > >>> > On Sat, Oct 1, 2016 at 9:14 PM, Luca Boccassi < >> > > >> >> > >>> [email protected]> >> > > >> >> > >>> > >>> wrote: >> > > >> >> > >>> > >>> > > On Tue, 2016-09-27 at 09:41 +0300, Doron Somech >> > > >> >> > >>> > >>> > > wrote: >> > > >> >> > >>> > >>> > >> Sorry for the late response, increasing the msg_t >> > > >> >> > >>> > >>> > >> structure >> > > >> >> > >>> will be >> > > >> >> > >>> > >>> > >> great, however this will require changing a lot of >> > > >> >> > >>> > >>> > >> binding. >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > > I think I remember we need it for the new socket >> > > >> >> > >>> > >>> > > types, >> > > >> >> > >>> > >>> > > is >> > > >> >> > >>> > >>> > > that >> > > >> >> > >>> > >>> correct? >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > > There is a large performance penalty (intuitively >> > > >> >> > >>> > >>> > > due >> > > >> >> > >>> > >>> > > to >> > > >> >> > >>> > >>> > > not >> > > >> >> > >>> fitting >> > > >> >> > >>> > >>> > > into a single cache line anymore, but haven't ran >> > > >> >> > >>> perf/cachegrind), >> > > >> >> > >>> > >>> and >> > > >> >> > >>> > >>> > > the throughput with vsm type messages goes down by >> > > >> >> > >>> > >>> > > 4% >> > > >> >> > >>> > >>> > > (min) >> > > >> >> > >>> and 20% >> > > >> >> > >>> > >>> > > (max) for TCP, and 36% (min) 38 (max) for inproc, >> > > >> >> > >>> > >>> > > which >> > > >> >> > >>> > >>> > > is >> > > >> >> > >>> quite a >> > > >> >> > >>> > >>> lot, >> > > >> >> > >>> > >>> > > so we need to be sure it's worth it. >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > > Regarding the bindings, after a quick search on the >> > > >> >> > >>> > >>> > > Github >> > > >> >> > >>> org, I >> > > >> >> > >>> > >>> could >> > > >> >> > >>> > >>> > > only see: >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > > https://github.com/zeromq/lzmq/blob/master/src/lua/lzmq/ >> > > >> >> > >>> > >>> ffi/api.lua#L144 >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > > https://github.com/zeromq/clrzmq4/blob/master/lib/zmq.cs#L28 >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > > https://github.com/zeromq/pyczmq/blob/master/pyczmq/zmq.py#L >> > > >> >> > >>> 177 >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > > Other bindings just import zmq.h. Did I miss any? >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > >> Sorry for disappearing, baby and full time job is >> > > >> >> > >>> > >>> > >> a >> > > >> >> > >>> > >>> > >> lot >> > > >> >> > >>> > >>> > >> :-), >> > > >> >> > >>> > >>> hopefully >> > > >> >> > >>> > >>> > >> I'm back... >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > > No worries, perfectly understandable :-) >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> > >> On Mon, Aug 29, 2016 at 6:46 PM, Luca Boccassi < >> > > >> >> > >>> > >>> [email protected]> wrote: >> > > >> >> > >>> > >>> > >> > Sorry, I meant if we go with (1), not (2), we >> > > >> >> > >>> > >>> > >> > might >> > > >> >> > >>> > >>> > >> > bump >> > > >> >> > >>> the size >> > > >> >> > >>> > >>> as >> > > >> >> > >>> > >>> > >> > well, since we are already doing another >> > > >> >> > >>> > >>> > >> > ABI-breaking >> > > >> >> > >>> change. >> > > >> >> > >>> > >>> > >> > >> > > >> >> > >>> > >>> > >> > I agree on the solution as well. >> > > >> >> > >>> > >>> > >> > >> > > >> >> > >>> > >>> > >> > On Mon, 2016-08-29 at 17:12 +0200, Pieter >> > > >> >> > >>> > >>> > >> > Hintjens >> > > >> >> > >>> > >>> > >> > wrote: >> > > >> >> > >>> > >>> > >> >> I'm confused between the (1) and (2) choices, >> > > >> >> > >>> > >>> > >> >> and >> > > >> >> > >>> > >>> > >> >> can't >> > > >> >> > >>> see where >> > > >> >> > >>> > >>> > >> >> bumping the message size fits. >> > > >> >> > >>> > >>> > >> >> >> > > >> >> > >>> > >>> > >> >> Nonetheless, I think bumping the size, fixing >> > > >> >> > >>> > >>> > >> >> the >> > > >> >> > >>> > >>> > >> >> alignment >> > > >> >> > >>> > >>> issues, >> > > >> >> > >>> > >>> > >> >> and bumping the ABI version is the best >> > > >> >> > >>> > >>> > >> >> solution >> > > >> >> > >>> > >>> > >> >> here. >> > > >> >> > >>> > >>> > >> >> >> > > >> >> > >>> > >>> > >> >> On Fri, Aug 26, 2016 at 12:33 PM, Luca >> > > >> >> > >>> > >>> > >> >> Boccassi < >> > > >> >> > >>> > >>> [email protected]> wrote: >> > > >> >> > >>> > >>> > >> >> > I've given some more thoughts and testing to >> > > >> >> > >>> > >>> > >> >> > the >> > > >> >> > >>> alignment >> > > >> >> > >>> > >>> issue. I can >> > > >> >> > >>> > >>> > >> >> > reproduce the problem by enabling alignment >> > > >> >> > >>> > >>> > >> >> > checks >> > > >> >> > >>> > >>> > >> >> > on >> > > >> >> > >>> x86 too. >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > But most importantly, I think we cannot get >> > > >> >> > >>> > >>> > >> >> > away >> > > >> >> > >>> > >>> > >> >> > from >> > > >> >> > >>> bumping >> > > >> >> > >>> > >>> the ABI >> > > >> >> > >>> > >>> > >> >> > with this fix, however we rearrange it, >> > > >> >> > >>> > >>> > >> >> > simply >> > > >> >> > >>> > >>> > >> >> > because >> > > >> >> > >>> > >>> applications need >> > > >> >> > >>> > >>> > >> >> > to be rebuilt against the new header to be >> > > >> >> > >>> > >>> > >> >> > fixed. >> > > >> >> > >>> > >>> > >> >> > A >> > > >> >> > >>> simple >> > > >> >> > >>> > >>> rebuild of >> > > >> >> > >>> > >>> > >> >> > the libzmq.so is not enough. And the way to >> > > >> >> > >>> > >>> > >> >> > do >> > > >> >> > >>> > >>> > >> >> > this >> > > >> >> > >>> > >>> > >> >> > is >> > > >> >> > >>> to bump >> > > >> >> > >>> > >>> the ABI >> > > >> >> > >>> > >>> > >> >> > so that distros can schedule transitions and >> > > >> >> > >>> > >>> > >> >> > rebuilds >> > > >> >> > >>> and so >> > > >> >> > >>> > >>> on. >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > So the choice list is now restricted to: >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > 1) Bump ABI >> > > >> >> > >>> > >>> > >> >> > 2) Revert the fix and leave everything >> > > >> >> > >>> > >>> > >> >> > broken on >> > > >> >> > >>> > >>> > >> >> > sparc64 >> > > >> >> > >>> and >> > > >> >> > >>> > >>> some >> > > >> >> > >>> > >>> > >> >> > aarch64 (rpi3 seems not to be affected, must >> > > >> >> > >>> > >>> > >> >> > depend >> > > >> >> > >>> > >>> > >> >> > on >> > > >> >> > >>> the SoC >> > > >> >> > >>> > >>> flavour) >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > If we go with 2, we might as well get 2 birds >> > > >> >> > >>> > >>> > >> >> > with >> > > >> >> > >>> > >>> > >> >> > one >> > > >> >> > >>> stone >> > > >> >> > >>> > >>> and bump >> > > >> >> > >>> > >>> > >> >> > the zmq_msg_t size to 128 as we have talked >> > > >> >> > >>> > >>> > >> >> > about >> > > >> >> > >>> > >>> > >> >> > in >> > > >> >> > >>> > >>> > >> >> > the >> > > >> >> > >>> past. >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > Doron, this would help with the new UDP based >> > > >> >> > >>> > >>> > >> >> > socket >> > > >> >> > >>> types >> > > >> >> > >>> > >>> right? >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > Pros of bumping msg size: >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > - we can get rid of the malloc() in the lmsg >> > > >> >> > >>> > >>> > >> >> > type >> > > >> >> > >>> > >>> > >> >> > case >> > > >> >> > >>> as all >> > > >> >> > >>> > >>> the data >> > > >> >> > >>> > >>> > >> >> > will fit >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > Cons: >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > - for the vsm/cmsg type cases (for most >> > > >> >> > >>> > >>> > >> >> > architectures >> > > >> >> > >>> anyway) >> > > >> >> > >>> > >>> it won't >> > > >> >> > >>> > >>> > >> >> > fit anymore into a single cacheline >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > Given all this, I'd say we should go for it. >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > Opinions? >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > On Sat, 2016-08-13 at 16:59 +0100, Luca >> > > >> >> > >>> > >>> > >> >> > Boccassi >> > > >> >> > >>> > >>> > >> >> > wrote: >> > > >> >> > >>> > >>> > >> >> >> Hello, >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> Trying to give some thoughts again on the >> > > >> >> > >>> > >>> > >> >> >> libzmq >> > > >> >> > >>> > >>> > >> >> >> 4.2 >> > > >> >> > >>> release. >> > > >> >> > >>> > >>> It's >> > > >> >> > >>> > >>> > >> >> >> really long overdue! >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> The main issue from my point of view is this >> > > >> >> > >>> > >>> > >> >> >> change: >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> https://github.com/zeromq/libzmq/commit/ >> > > >> >> > >>> > >>> d9fb1d36ff2008966af538f722a1f4ab158dbf64 >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> -typedef struct zmq_msg_t {unsigned char _ >> > > >> >> > >>> > >>> > >> >> >> [64];} >> > > >> >> > >>> zmq_msg_t; >> > > >> >> > >>> > >>> > >> >> >> +/* union here ensures correct alignment on >> > > >> >> > >>> architectures >> > > >> >> > >>> > >>> that require >> > > >> >> > >>> > >>> > >> >> >> it, e.g. >> > > >> >> > >>> > >>> > >> >> >> + * SPARC >> > > >> >> > >>> > >>> > >> >> >> + */ >> > > >> >> > >>> > >>> > >> >> >> +typedef union zmq_msg_t {unsigned char _ >> > > >> >> > >>> > >>> > >> >> >> [64]; >> > > >> >> > >>> > >>> > >> >> >> void >> > > >> >> > >>> *p; } >> > > >> >> > >>> > >>> zmq_msg_t; >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> This is flagged by the common ABI checkers >> > > >> >> > >>> > >>> > >> >> >> tools >> > > >> >> > >>> > >>> > >> >> >> as >> > > >> >> > >>> > >>> > >> >> >> an >> > > >> >> > >>> ABI >> > > >> >> > >>> > >>> breakage >> > > >> >> > >>> > >>> > >> >> >> (see: http://abi-laboratory.pro/trac >> > > >> >> > >>> ker/timeline/zeromq/ ). >> > > >> >> > >>> > >>> And it makes >> > > >> >> > >>> > >>> > >> >> >> sense from this point of view: if some >> > > >> >> > >>> > >>> > >> >> >> applications >> > > >> >> > >>> > >>> > >> >> >> on >> > > >> >> > >>> some >> > > >> >> > >>> > >>> > >> >> >> architectures are broken due to wrong >> > > >> >> > >>> > >>> > >> >> >> alignment, >> > > >> >> > >>> > >>> > >> >> >> they >> > > >> >> > >>> would >> > > >> >> > >>> > >>> need to be >> > > >> >> > >>> > >>> > >> >> >> rebuilt, and the way to ensure that is to >> > > >> >> > >>> > >>> > >> >> >> bump >> > > >> >> > >>> > >>> > >> >> >> the >> > > >> >> > >>> > >>> > >> >> >> ABI >> > > >> >> > >>> > >>> "current" digit >> > > >> >> > >>> > >>> > >> >> >> to make sure maintainers do a rebuild. >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> On the other hand, signaling an ABI >> > > >> >> > >>> > >>> > >> >> >> breakage is >> > > >> >> > >>> > >>> > >> >> >> a >> > > >> >> > >>> > >>> > >> >> >> pain, >> > > >> >> > >>> and a >> > > >> >> > >>> > >>> cause of >> > > >> >> > >>> > >>> > >> >> >> major churn for packagers and maintainers. >> > > >> >> > >>> > >>> > >> >> >> It >> > > >> >> > >>> > >>> > >> >> >> means >> > > >> >> > >>> > >>> > >> >> >> for >> > > >> >> > >>> > >>> example a new >> > > >> >> > >>> > >>> > >> >> >> package has to be created (eg: libzmq5 -> >> > > >> >> > >>> > >>> > >> >> >> libzmq6), >> > > >> >> > >>> > >>> > >> >> >> and >> > > >> >> > >>> a >> > > >> >> > >>> > >>> transition has >> > > >> >> > >>> > >>> > >> >> >> to be started and all reverse dependencies >> > > >> >> > >>> > >>> > >> >> >> need >> > > >> >> > >>> > >>> > >> >> >> to >> > > >> >> > >>> > >>> > >> >> >> be >> > > >> >> > >>> > >>> rebuilt. And if >> > > >> >> > >>> > >>> > >> >> >> this is pointless for all save a few corner >> > > >> >> > >>> > >>> > >> >> >> cases >> > > >> >> > >>> > >>> > >> >> >> (eg >> > > >> >> > >>> SPARC64 >> > > >> >> > >>> > >>> as for >> > > >> >> > >>> > >>> > >> >> >> above) it's all quite frustrating. >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> So we have a choice to make before we >> > > >> >> > >>> > >>> > >> >> >> release >> > > >> >> > >>> > >>> > >> >> >> 4.2, >> > > >> >> > >>> > >>> > >> >> >> four >> > > >> >> > >>> > >>> possibilities as >> > > >> >> > >>> > >>> > >> >> >> far as I can see: >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> 1) Ignore the ABI checkers and get yelled >> > > >> >> > >>> > >>> > >> >> >> at by >> > > >> >> > >>> maintainers >> > > >> >> > >>> > >>> and >> > > >> >> > >>> > >>> > >> >> >> packagers. Also the SPARC64 users will most >> > > >> >> > >>> > >>> > >> >> >> likely >> > > >> >> > >>> > >>> > >> >> >> NOT >> > > >> >> > >>> get >> > > >> >> > >>> > >>> their bug >> > > >> >> > >>> > >>> > >> >> >> fixed >> > > >> >> > >>> > >>> > >> >> >> 2) Bump ABI revision to 6 and get yelled at >> > > >> >> > >>> > >>> > >> >> >> by >> > > >> >> > >>> maintainers >> > > >> >> > >>> > >>> and packagers >> > > >> >> > >>> > >>> > >> >> >> 3) Revert the above change and postpone it >> > > >> >> > >>> > >>> > >> >> >> to >> > > >> >> > >>> > >>> > >> >> >> when >> > > >> >> > >>> > >>> > >> >> >> we >> > > >> >> > >>> have a >> > > >> >> > >>> > >>> more >> > > >> >> > >>> > >>> > >> >> >> generally useful reason to break ABI (bump >> > > >> >> > >>> > >>> > >> >> >> zmq_msg_t >> > > >> >> > >>> from 64 >> > > >> >> > >>> > >>> to 128 >> > > >> >> > >>> > >>> > >> >> >> bytes for example, Doron?) >> > > >> >> > >>> > >>> > >> >> >> 4) Try to be clever and revert the above >> > > >> >> > >>> > >>> > >> >> >> change >> > > >> >> > >>> > >>> > >> >> >> and >> > > >> >> > >>> > >>> > >> >> >> use >> > > >> >> > >>> > >>> something like >> > > >> >> > >>> > >>> > >> >> >> #pragma pack(8). This will fool the ABI >> > > >> >> > >>> > >>> > >> >> >> checkers >> > > >> >> > >>> > >>> > >> >> >> (I >> > > >> >> > >>> tried >> > > >> >> > >>> > >>> it), and given >> > > >> >> > >>> > >>> > >> >> >> that typedef is only used externally to >> > > >> >> > >>> > >>> > >> >> >> allocate >> > > >> >> > >>> > >>> > >> >> >> the >> > > >> >> > >>> right >> > > >> >> > >>> > >>> size it >> > > >> >> > >>> > >>> > >> >> >> shouldn't actually affect anything, apart >> > > >> >> > >>> > >>> > >> >> >> from >> > > >> >> > >>> > >>> > >> >> >> the >> > > >> >> > >>> users of >> > > >> >> > >>> > >>> SPARC64 >> > > >> >> > >>> > >>> > >> >> >> which should get the bugfix with this too. >> > > >> >> > >>> > >>> > >> >> >> This >> > > >> >> > >>> > >>> > >> >> >> is >> > > >> >> > >>> > >>> > >> >> >> very >> > > >> >> > >>> > >>> sneaky :-) >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> CC'ing Lazslo, the Debian maintainer, given >> > > >> >> > >>> > >>> > >> >> >> what >> > > >> >> > >>> > >>> > >> >> >> we >> > > >> >> > >>> choose to >> > > >> >> > >>> > >>> do might >> > > >> >> > >>> > >>> > >> >> >> result in a lot of work for him :-) >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> Opinions? >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> Kind regards, >> > > >> >> > >>> > >>> > >> >> >> Luca Boccassi >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> On Tue, 2016-05-03 at 10:39 +0200, Pieter >> > > >> >> > >>> > >>> > >> >> >> Hintjens >> > > >> >> > >>> wrote: >> > > >> >> > >>> > >>> > >> >> >> > Hi all, >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > I'm just throwing some ideas on the >> > > >> >> > >>> > >>> > >> >> >> > table. We >> > > >> >> > >>> > >>> > >> >> >> > have a >> > > >> >> > >>> good >> > > >> >> > >>> > >>> package of >> > > >> >> > >>> > >>> > >> >> >> > work on master and it's probably time to >> > > >> >> > >>> > >>> > >> >> >> > make >> > > >> >> > >>> > >>> > >> >> >> > a >> > > >> >> > >>> > >>> > >> >> >> > 4.2 >> > > >> >> > >>> release. >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > Luca has already back-ported the >> > > >> >> > >>> > >>> > >> >> >> > enable/disable >> > > >> >> > >>> > >>> > >> >> >> > draft >> > > >> >> > >>> > >>> design from >> > > >> >> > >>> > >>> > >> >> >> > zproject (CZMQ et al). Yay! So we can now >> > > >> >> > >>> > >>> > >> >> >> > release >> > > >> >> > >>> stable >> > > >> >> > >>> > >>> master >> > > >> >> > >>> > >>> > >> >> >> > safely, while continuing to refine and >> > > >> >> > >>> > >>> > >> >> >> > extend >> > > >> >> > >>> > >>> > >> >> >> > the >> > > >> >> > >>> draft API >> > > >> >> > >>> > >>> sections. >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > I propose: >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > - to end with the stable fork policy; >> > > >> >> > >>> > >>> > >> >> >> > this was >> > > >> >> > >>> > >>> > >> >> >> > needed >> > > >> >> > >>> years >> > > >> >> > >>> > >>> ago when >> > > >> >> > >>> > >>> > >> >> >> > we had massively unstable masters. It's no >> > > >> >> > >>> > >>> > >> >> >> > longer >> > > >> >> > >>> > >>> > >> >> >> > a >> > > >> >> > >>> problem. >> > > >> >> > >>> > >>> > >> >> >> > - to use the github release function for >> > > >> >> > >>> > >>> > >> >> >> > libzmq >> > > >> >> > >>> releases >> > > >> >> > >>> > >>> and deprecate >> > > >> >> > >>> > >>> > >> >> >> > the separate delivery of tarballs. >> > > >> >> > >>> > >>> > >> >> >> > - we aim to make a 4.2.0 rc asap, then >> > > >> >> > >>> > >>> > >> >> >> > fix any >> > > >> >> > >>> > >>> > >> >> >> > issues >> > > >> >> > >>> we >> > > >> >> > >>> > >>> get, with >> > > >> >> > >>> > >>> > >> >> >> > patch releases as usual. >> > > >> >> > >>> > >>> > >> >> >> > - we backport the release function to >> > > >> >> > >>> > >>> > >> >> >> > older >> > > >> >> > >>> > >>> > >> >> >> > maintained >> > > >> >> > >>> > >>> releases (4.1, >> > > >> >> > >>> > >>> > >> >> >> > 3.2) so that their tarballs are provided >> > > >> >> > >>> > >>> > >> >> >> > by >> > > >> >> > >>> > >>> > >> >> >> > github >> > > >> >> > >>> instead >> > > >> >> > >>> > >>> of >> > > >> >> > >>> > >>> > >> >> >> > downloads.zeromq.org. >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > Problems: >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > - this will break a few things that >> > > >> >> > >>> > >>> > >> >> >> > depend on >> > > >> >> > >>> > >>> downloads.zeromq.org. To >> > > >> >> > >>> > >>> > >> >> >> > be fixed as we go. >> > > >> >> > >>> > >>> > >> >> >> > - github tarballs are not identical to >> > > >> >> > >>> > >>> > >> >> >> > source >> > > >> >> > >>> tarballs, >> > > >> >> > >>> > >>> particularly >> > > >> >> > >>> > >>> > >> >> >> > they lack `configure`. I propose changing >> > > >> >> > >>> > >>> > >> >> >> > our >> > > >> >> > >>> autotools >> > > >> >> > >>> > >>> build >> > > >> >> > >>> > >>> > >> >> >> > instructions so they always start with >> > > >> >> > >>> > >>> > >> >> >> > `./autogen,sh` >> > > >> >> > >>> no >> > > >> >> > >>> > >>> matter where >> > > >> >> > >>> > >>> > >> >> >> > the sources come from. >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > I think this will work and also let us >> > > >> >> > >>> > >>> > >> >> >> > gracefully >> > > >> >> > >>> > >>> deprecate/switch off >> > > >> >> > >>> > >>> > >> >> >> > the downloads box. >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > -Pieter >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > _______________________________________________ >> > > >> >> > >>> > >>> > >> >> >> > zeromq-dev mailing list >> > > >> >> > >>> > >>> > >> >> >> > [email protected] >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > >> > > >> >> > >>> > >>> > >> >> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> >> >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > _______________________________________________ >> > > >> >> > >>> > >>> > >> >> > zeromq-dev mailing list >> > > >> >> > >>> > >>> > >> >> > [email protected] >> > > >> >> > >>> > >>> > >> >> > >> > > >> >> > >>> > >>> > >> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > >> >> > >>> > >>> > >> >> _______________________________________________ >> > > >> >> > >>> > >>> > >> >> zeromq-dev mailing list >> > > >> >> > >>> > >>> > >> >> [email protected] >> > > >> >> > >>> > >>> > >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > >> >> > >>> > >>> > >> > >> > > >> >> > >>> > >>> > >> > >> > > >> >> > >>> > >>> > > >> > > >> >> > >>> > >>> >> > > >> >> > >>> > >>> _______________________________________________ >> > > >> >> > >>> > >> zeromq-dev mailing list >> > > >> >> > >>> > >> [email protected] >> > > >> >> > >>> > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > >> >> > >>> > > >> > > >> >> > >>> > > >> > > >> >> > >>> > _______________________________________________ >> > > >> >> > >>> > zeromq-dev mailing list >> > > >> >> > >>> > [email protected] >> > > >> >> > >>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > >> >> > >>> >> > > >> >> > >>> >> > > >> >> > >>> >> > > >> >> >> > > >> >> >> > > >> > >> > >> > >> >> > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev -- best regards Michal Vyskocil _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
