| Message ID | 1381509097-5424-1-git-send-email-jerzy.grzegorek@trzebnica.net |
|---|---|
| State | Accepted |
| Commit | 9876471082c017132b53ec0a420a298db9aa78a0 |
| Headers | show |
Dear Jerzy Grzegorek, On Fri, 11 Oct 2013 18:31:37 +0200, Jerzy Grzegorek wrote: > Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> > --- > package/zeromq/zeromq.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/package/zeromq/zeromq.mk b/package/zeromq/zeromq.mk > index a624b52..d40bed5 100644 > --- a/package/zeromq/zeromq.mk > +++ b/package/zeromq/zeromq.mk > @@ -4,7 +4,7 @@ > # > ################################################################################ > > -ZEROMQ_VERSION = 3.2.4 > +ZEROMQ_VERSION = 4.0.1 > ZEROMQ_SITE = http://download.zeromq.org/ > ZEROMQ_INSTALL_STAGING = YES > ZEROMQ_DEPENDENCIES = util-linux I tried to apply this patch, but unfortunately, it apparently breaks the build of mongrel2: src/superpoll.c: In function ‘SuperPoll_poll’: src/superpoll.c:229:53: error: ‘ZMQ_POLL_MSEC’ undeclared (first use in this function) src/superpoll.c:229:53: note: each undeclared identifier is reported only once for each function it appears in I've checked the other reverse dependencies of zeromq, and they seem to build fine. Can you find a solution to the mongrel2 problem, and resubmit the appropriate patch? Thanks! Thomas
Dear Jerzy and Thomas, On Sat, Mar 1, 2014 at 11:25 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Dear Jerzy Grzegorek, > > On Fri, 11 Oct 2013 18:31:37 +0200, Jerzy Grzegorek wrote: >> Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> >> --- >> package/zeromq/zeromq.mk | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/package/zeromq/zeromq.mk b/package/zeromq/zeromq.mk >> index a624b52..d40bed5 100644 >> --- a/package/zeromq/zeromq.mk >> +++ b/package/zeromq/zeromq.mk >> @@ -4,7 +4,7 @@ >> # >> ################################################################################ >> >> -ZEROMQ_VERSION = 3.2.4 >> +ZEROMQ_VERSION = 4.0.1 >> ZEROMQ_SITE = http://download.zeromq.org/ >> ZEROMQ_INSTALL_STAGING = YES >> ZEROMQ_DEPENDENCIES = util-linux > > I tried to apply this patch, but unfortunately, it apparently breaks > the build of mongrel2: > > src/superpoll.c: In function 'SuperPoll_poll': > src/superpoll.c:229:53: error: 'ZMQ_POLL_MSEC' undeclared (first use in this function) > src/superpoll.c:229:53: note: each undeclared identifier is reported only once for each function it appears in > > I've checked the other reverse dependencies of zeromq, and they seem to > build fine. > > Can you find a solution to the mongrel2 problem, and resubmit the > appropriate patch? Such a patch would fix compilation, but the fact is this version of Mongrel2 was not tested with ZeroMQ v4 and greater and I don't know if we can simply bump its version like that. Maybe we can but I am not 100% sure. On another hand, mongrel2 development is becoming active again and they are trying to prepare a release, so I will try to check there if they ensure zeromq4 compliance and tested it. I will get back to you when I can on this subject. > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot Best regards, Lionel
Dear Lionel Orry, On Mon, 3 Mar 2014 07:51:45 +0100, Lionel Orry wrote: > > I tried to apply this patch, but unfortunately, it apparently breaks > > the build of mongrel2: > > > > src/superpoll.c: In function 'SuperPoll_poll': > > src/superpoll.c:229:53: error: 'ZMQ_POLL_MSEC' undeclared (first use in this function) > > src/superpoll.c:229:53: note: each undeclared identifier is reported only once for each function it appears in > > > > I've checked the other reverse dependencies of zeromq, and they seem to > > build fine. > > > > Can you find a solution to the mongrel2 problem, and resubmit the > > appropriate patch? > > Such a patch would fix compilation, but the fact is this version of What do you mean by "such a patch" ? Maybe you forgot to attach a patch to your e-mail? > Mongrel2 was not tested with ZeroMQ v4 and greater > and I don't know if we can simply bump its version like that. Maybe we > can but I am not 100% sure. > > On another hand, mongrel2 development is becoming active again and > they are trying to prepare a release, so I will try to check there if > they ensure zeromq4 compliance and tested it. I will get back to you > when I can on this subject. Ok, thanks! Does ZeroMQ v4 changes the API/behavior a lot compared to v3 ? Best regards, Thomas
Dear Thomas, On Mon, Mar 3, 2014 at 8:47 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Dear Lionel Orry, > > On Mon, 3 Mar 2014 07:51:45 +0100, Lionel Orry wrote: > >> > I tried to apply this patch, but unfortunately, it apparently breaks >> > the build of mongrel2: >> > >> > src/superpoll.c: In function 'SuperPoll_poll': >> > src/superpoll.c:229:53: error: 'ZMQ_POLL_MSEC' undeclared (first use in this function) >> > src/superpoll.c:229:53: note: each undeclared identifier is reported only once for each function it appears in >> > >> > I've checked the other reverse dependencies of zeromq, and they seem to >> > build fine. >> > >> > Can you find a solution to the mongrel2 problem, and resubmit the >> > appropriate patch? >> >> Such a patch would fix compilation, but the fact is this version of > > What do you mean by "such a patch" ? Maybe you forgot to attach a patch > to your e-mail? um no, I meant the "appropriate patch" you were suggesting Jerzy to prepare so that mongrel2 compiles. If I understood correctly. > >> Mongrel2 was not tested with ZeroMQ v4 and greater >> and I don't know if we can simply bump its version like that. Maybe we >> can but I am not 100% sure. >> >> On another hand, mongrel2 development is becoming active again and >> they are trying to prepare a release, so I will try to check there if >> they ensure zeromq4 compliance and tested it. I will get back to you >> when I can on this subject. > > Ok, thanks! > > Does ZeroMQ v4 changes the API/behavior a lot compared to v3 ? The v2 -> v3 transistion has been a nightmare more many devs, but they learnt from it and it seems the v3->v4 is much smoother. By the way, I noticed the mongrel2 devs tagged a v1.9.0 a month ago, and this release includes a zeromq4 compliance, plus other fixes and enhancements. May I suggest we simply bump the mongrel2 version ? > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com BR, Lionel
Dear Lionel Orry, On Mon, 3 Mar 2014 09:14:44 +0100, Lionel Orry wrote: > > What do you mean by "such a patch" ? Maybe you forgot to attach a patch > > to your e-mail? > > um no, I meant the "appropriate patch" you were suggesting Jerzy to > prepare so that mongrel2 compiles. If I understood correctly. Ah ok. > > Does ZeroMQ v4 changes the API/behavior a lot compared to v3 ? > > The v2 -> v3 transistion has been a nightmare more many devs, but they > learnt from it and it seems the v3->v4 is much smoother. > > By the way, I noticed the mongrel2 devs tagged a v1.9.0 a month ago, > and this release includes a zeromq4 compliance, plus other fixes and > enhancements. May I suggest we simply bump the mongrel2 version ? Indeed, seems like the best solution. Jerzy, can you have a look into this? Thanks! Thomas
Jerzy, Lionel, On Mon, Mar 3, 2014 at 11:11 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Dear Lionel Orry, > > On Mon, 3 Mar 2014 09:14:44 +0100, Lionel Orry wrote: > >> > What do you mean by "such a patch" ? Maybe you forgot to attach a patch >> > to your e-mail? >> >> um no, I meant the "appropriate patch" you were suggesting Jerzy to >> prepare so that mongrel2 compiles. If I understood correctly. > > Ah ok. > >> > Does ZeroMQ v4 changes the API/behavior a lot compared to v3 ? >> >> The v2 -> v3 transistion has been a nightmare more many devs, but they >> learnt from it and it seems the v3->v4 is much smoother. >> >> By the way, I noticed the mongrel2 devs tagged a v1.9.0 a month ago, >> and this release includes a zeromq4 compliance, plus other fixes and >> enhancements. May I suggest we simply bump the mongrel2 version ? > > Indeed, seems like the best solution. > > Jerzy, can you have a look into this? Any of you interested in reviving this patch, bumping mongrel2 at the same time? Thanks, Thomas
Hi Thomas, On Mon, Apr 7, 2014 at 4:32 PM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: > Jerzy, Lionel, > > On Mon, Mar 3, 2014 at 11:11 AM, Thomas Petazzoni > <thomas.petazzoni@free-electrons.com> wrote: >> Dear Lionel Orry, >> >> On Mon, 3 Mar 2014 09:14:44 +0100, Lionel Orry wrote: >> >>> > What do you mean by "such a patch" ? Maybe you forgot to attach a patch >>> > to your e-mail? >>> >>> um no, I meant the "appropriate patch" you were suggesting Jerzy to >>> prepare so that mongrel2 compiles. If I understood correctly. >> >> Ah ok. >> >>> > Does ZeroMQ v4 changes the API/behavior a lot compared to v3 ? >>> >>> The v2 -> v3 transistion has been a nightmare more many devs, but they >>> learnt from it and it seems the v3->v4 is much smoother. >>> >>> By the way, I noticed the mongrel2 devs tagged a v1.9.0 a month ago, >>> and this release includes a zeromq4 compliance, plus other fixes and >>> enhancements. May I suggest we simply bump the mongrel2 version ? >> >> Indeed, seems like the best solution. >> >> Jerzy, can you have a look into this? > > Any of you interested in reviving this patch, bumping mongrel2 at the same time? As soon as I have time, I'll prepare a patch for mongrel2 bump version, which should solve quite everything on the subject. Don't hesitate to ping me if I am taking too much time :) > > Thanks, > Thomas Cheers, Lionel
Hi all, On Mon, Apr 7, 2014 at 4:32 PM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: > Jerzy, Lionel, > > On Mon, Mar 3, 2014 at 11:11 AM, Thomas Petazzoni > <thomas.petazzoni@free-electrons.com> wrote: >> Dear Lionel Orry, >> >> On Mon, 3 Mar 2014 09:14:44 +0100, Lionel Orry wrote: >> >>> > What do you mean by "such a patch" ? Maybe you forgot to attach a patch >>> > to your e-mail? >>> >>> um no, I meant the "appropriate patch" you were suggesting Jerzy to >>> prepare so that mongrel2 compiles. If I understood correctly. >> >> Ah ok. >> >>> > Does ZeroMQ v4 changes the API/behavior a lot compared to v3 ? >>> >>> The v2 -> v3 transistion has been a nightmare more many devs, but they >>> learnt from it and it seems the v3->v4 is much smoother. >>> >>> By the way, I noticed the mongrel2 devs tagged a v1.9.0 a month ago, >>> and this release includes a zeromq4 compliance, plus other fixes and >>> enhancements. May I suggest we simply bump the mongrel2 version ? >> >> Indeed, seems like the best solution. >> >> Jerzy, can you have a look into this? > > Any of you interested in reviving this patch, bumping mongrel2 at the same time? Quick news : mongrel v1.9.0 depends on polarssl now. But they decided to declare this dependency as a git submodule of their repo, and the release tarball being taken directly from github does not include the polarssl code. In short, they release tarball is unuseable. I'll talk about it upstream. To make it clean, I'll try to get rid of the git submodule dep and make attempts with the polarssl buildroot package. The bad (or not?) news is that mongrel2 depends on polarssl v1.3.0 (v1.3.x if polarssl properly versions its library, I think it is the case) and we currently use polarssl v1.2.10, so a polarssl bump version is needed first. Does anyone know what implications could a polarssl minor version bump have ? I already saw some of the polarssl patches don't apply properly so they need to be revisited. Gustavo, I think you were in charge of the last polarssl bump, do you think you could help with this one, or say whether it is a very bad idea to bump the package version ? Thanks everyone, Lionel > > Thanks, > Thomas
On 04/08/2014 04:32 AM, Lionel Orry wrote: > Quick news : mongrel v1.9.0 depends on polarssl now. But they decided > to declare this dependency as a git submodule of their repo, and the > release tarball being taken directly from github does not include the > polarssl code. In short, they release tarball is unuseable. I'll talk > about it upstream. > > To make it clean, I'll try to get rid of the git submodule dep and > make attempts with the polarssl buildroot package. > > The bad (or not?) news is that mongrel2 depends on polarssl v1.3.0 > (v1.3.x if polarssl properly versions its library, I think it is the > case) and we currently use polarssl v1.2.10, so a polarssl bump > version is needed first. > > Does anyone know what implications could a polarssl minor version bump > have ? I already saw some of the polarssl patches don't apply properly > so they need to be revisited. Gustavo, I think you were in charge of > the last polarssl bump, do you think you could help with this one, or > say whether it is a very bad idea to bump the package version ? > > Thanks everyone, > Lionel Hi. It breaks at least openvpn since the API isn't 100% compatible with the 1.2.x series and openvpn doesn't handle 1.3.x yet. Hiawatha has a new version which bundles/works with 1.3.x. I haven't tried with libcurl but my gut tells me it should work since they update often. Dunno about rtmpdump. It may be possible to make them live side-by-side by making a polarssl13 package, though it may need to reside in a non-default prefix. Another possible solution is to fetch openvpn patches from git to make it compatible, but last time i checked (several months ago) there were none - that may have changed though. I'll take a look and get back a bit later. Regards.
Hi, On Tue, Apr 8, 2014 at 12:13 PM, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote: > On 04/08/2014 04:32 AM, Lionel Orry wrote: > >> Quick news : mongrel v1.9.0 depends on polarssl now. But they decided >> to declare this dependency as a git submodule of their repo, and the >> release tarball being taken directly from github does not include the >> polarssl code. In short, they release tarball is unuseable. I'll talk >> about it upstream. >> >> To make it clean, I'll try to get rid of the git submodule dep and >> make attempts with the polarssl buildroot package. >> >> The bad (or not?) news is that mongrel2 depends on polarssl v1.3.0 >> (v1.3.x if polarssl properly versions its library, I think it is the >> case) and we currently use polarssl v1.2.10, so a polarssl bump >> version is needed first. >> >> Does anyone know what implications could a polarssl minor version bump >> have ? I already saw some of the polarssl patches don't apply properly >> so they need to be revisited. Gustavo, I think you were in charge of >> the last polarssl bump, do you think you could help with this one, or >> say whether it is a very bad idea to bump the package version ? >> >> Thanks everyone, >> Lionel > > Hi. > It breaks at least openvpn since the API isn't 100% compatible with the > 1.2.x series and openvpn doesn't handle 1.3.x yet. > Hiawatha has a new version which bundles/works with 1.3.x. > I haven't tried with libcurl but my gut tells me it should work since > they update often. > Dunno about rtmpdump. > It may be possible to make them live side-by-side by making a polarssl13 > package, though it may need to reside in a non-default prefix. > Another possible solution is to fetch openvpn patches from git to make > it compatible, but last time i checked (several months ago) there were > none - that may have changed though. > I'll take a look and get back a bit later. Thanks a lot. In the meantime, I asked upstream for the possibility to build a proper release tarball including the polarssl source code, so that the version bump would not be necessary. > Regards. > Kind regards, Lionel
On 04/08/2014 07:28 AM, Lionel Orry wrote: >> Hi. >> It breaks at least openvpn since the API isn't 100% compatible with the >> 1.2.x series and openvpn doesn't handle 1.3.x yet. >> Hiawatha has a new version which bundles/works with 1.3.x. >> I haven't tried with libcurl but my gut tells me it should work since >> they update often. >> Dunno about rtmpdump. >> It may be possible to make them live side-by-side by making a polarssl13 >> package, though it may need to reside in a non-default prefix. >> Another possible solution is to fetch openvpn patches from git to make >> it compatible, but last time i checked (several months ago) there were >> none - that may have changed though. >> I'll take a look and get back a bit later. > > Thanks a lot. In the meantime, I asked upstream for the possibility to > build a proper release tarball including the polarssl source code, so > that the version bump would not be necessary. openvpn git mater is a no go, same with rtmpdump. If they ship the tarball that'd be great, otherwise we can look into packaging polarssl13. Fortunately upstream still considers polarssl12 maintained and there are security bumps if need be (not affected by the latest openssl/tls bug). There's always the option of helping/patching the offending packages to support it, but i'd rather not go there ;) Or the last option of kicking the polarssl backend from them and just keeping openssl/gnutls. Regards.
Hi, On Tue, Apr 8, 2014 at 12:38 PM, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote: > On 04/08/2014 07:28 AM, Lionel Orry wrote: > >>> Hi. >>> It breaks at least openvpn since the API isn't 100% compatible with the >>> 1.2.x series and openvpn doesn't handle 1.3.x yet. >>> Hiawatha has a new version which bundles/works with 1.3.x. >>> I haven't tried with libcurl but my gut tells me it should work since >>> they update often. >>> Dunno about rtmpdump. >>> It may be possible to make them live side-by-side by making a polarssl13 >>> package, though it may need to reside in a non-default prefix. >>> Another possible solution is to fetch openvpn patches from git to make >>> it compatible, but last time i checked (several months ago) there were >>> none - that may have changed though. >>> I'll take a look and get back a bit later. >> >> Thanks a lot. In the meantime, I asked upstream for the possibility to >> build a proper release tarball including the polarssl source code, so >> that the version bump would not be necessary. > > openvpn git mater is a no go, same with rtmpdump. > If they ship the tarball that'd be great, otherwise we can look into > packaging polarssl13. I eventually found a correct release tarball while looking deeper. The default url generated by the github helper confused me. I just sent a patch ! > Fortunately upstream still considers polarssl12 maintained and there are > security bumps if need be (not affected by the latest openssl/tls bug). > There's always the option of helping/patching the offending packages to > support it, but i'd rather not go there ;) > Or the last option of kicking the polarssl backend from them and just > keeping openssl/gnutls. > Regards. > Regards, Lionel
Hi Thomas and Jerzy, On Sat, Mar 1, 2014 at 11:25 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Dear Jerzy Grzegorek, > > On Fri, 11 Oct 2013 18:31:37 +0200, Jerzy Grzegorek wrote: >> Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> >> --- >> package/zeromq/zeromq.mk | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/package/zeromq/zeromq.mk b/package/zeromq/zeromq.mk >> index a624b52..d40bed5 100644 >> --- a/package/zeromq/zeromq.mk >> +++ b/package/zeromq/zeromq.mk >> @@ -4,7 +4,7 @@ >> # >> ################################################################################ >> >> -ZEROMQ_VERSION = 3.2.4 >> +ZEROMQ_VERSION = 4.0.1 >> ZEROMQ_SITE = http://download.zeromq.org/ >> ZEROMQ_INSTALL_STAGING = YES >> ZEROMQ_DEPENDENCIES = util-linux > > I tried to apply this patch, but unfortunately, it apparently breaks > the build of mongrel2: > > src/superpoll.c: In function 'SuperPoll_poll': > src/superpoll.c:229:53: error: 'ZMQ_POLL_MSEC' undeclared (first use in this function) > src/superpoll.c:229:53: note: each undeclared identifier is reported only once for each function it appears in > > I've checked the other reverse dependencies of zeromq, and they seem to > build fine. > > Can you find a solution to the mongrel2 problem, and resubmit the > appropriate patch? So now that mongrel2 is bumped to v1.9.0 (and tested against zmq v4.0.1), can we reconsider this patch please ? > > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot Best regards, Lionel
>>>>> "Lionel" == Lionel Orry <lionel.orry@gmail.com> writes: Hi, >> Can you find a solution to the mongrel2 problem, and resubmit the >> appropriate patch? > So now that mongrel2 is bumped to v1.9.0 (and tested against zmq > v4.0.1), can we reconsider this patch please ? Yes, I'll take care of it.
>>>>> "Jerzy" == Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> writes: > Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> Committed, thanks.
diff --git a/package/zeromq/zeromq.mk b/package/zeromq/zeromq.mk index a624b52..d40bed5 100644 --- a/package/zeromq/zeromq.mk +++ b/package/zeromq/zeromq.mk @@ -4,7 +4,7 @@ # ################################################################################ -ZEROMQ_VERSION = 3.2.4 +ZEROMQ_VERSION = 4.0.1 ZEROMQ_SITE = http://download.zeromq.org/ ZEROMQ_INSTALL_STAGING = YES ZEROMQ_DEPENDENCIES = util-linux
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> --- package/zeromq/zeromq.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)