Patchwork [1/1] openpgm: new package

login
register
mail settings
Submitter Alexander Lukichev
Date Feb. 11, 2013, 12:30 p.m.
Message ID <1360585826-17996-1-git-send-email-alexander.lukichev@gmail.com>
Download mbox | patch
Permalink /patch/219596/
State Superseded
Headers show

Comments

Alexander Lukichev - Feb. 11, 2013, 12:30 p.m.
From: Alexander Lukichev <alexander.lukichev@espotel.com>

OpenPGM is an open source implementation of the Pragmatic General
Multicast (PGM) specification in RFC 3208 available at www.ietf.org.
It may be required for PGM/EPGM support in ZeroMQ library. This
adds version 5.1.118-1~dfsg of the package, required by
zeromq-2.2.0. It also adds a patch for cross-compilation of
more recent 5.2.121~dfsg version.

Signed-off-by: Alexander Lukichev <alexander.lukichev@gmail.com>
---
 package/Config.in                                  |  1 +
 package/openpgm/Config.in                          | 10 ++++++++++
 .../openpgm-5.1.118-1~dfsg-cross-compile.patch     | 13 ++++++++++++
 .../openpgm-5.2.121~dfsg-cross-compile.patch       | 13 ++++++++++++
 package/openpgm/openpgm.mk                         | 23 ++++++++++++++++++++++
 5 files changed, 60 insertions(+)
 create mode 100644 package/openpgm/Config.in
 create mode 100644 package/openpgm/openpgm-5.1.118-1~dfsg-cross-compile.patch
 create mode 100644 package/openpgm/openpgm-5.2.121~dfsg-cross-compile.patch
 create mode 100644 package/openpgm/openpgm.mk
Thomas Petazzoni - Feb. 11, 2013, 12:45 p.m.
Dear Alexander Lukichev,

On Mon, 11 Feb 2013 14:30:26 +0200, Alexander Lukichev wrote:
> From: Alexander Lukichev <alexander.lukichev@espotel.com>
> 
> OpenPGM is an open source implementation of the Pragmatic General
> Multicast (PGM) specification in RFC 3208 available at www.ietf.org.
> It may be required for PGM/EPGM support in ZeroMQ library. This
> adds version 5.1.118-1~dfsg of the package, required by
> zeromq-2.2.0. It also adds a patch for cross-compilation of
> more recent 5.2.121~dfsg version.

We no longer want to have patches that contain the package version in
their filename.

Any reason not to package the most recent version available? Are there
incompatibilities between 5.1.118 and 5.2.121 that makes 5.2.121
unusable for zeromq?

> diff --git a/package/openpgm/openpgm-5.1.118-1~dfsg-cross-compile.patch b/package/openpgm/openpgm-5.1.118-1~dfsg-cross-compile.patch
> new file mode 100644
> index 0000000..2e16c0d
> --- /dev/null
> +++ b/package/openpgm/openpgm-5.1.118-1~dfsg-cross-compile.patch
> @@ -0,0 +1,13 @@
> +diff -uNrp a/configure.ac b/configure.ac
> +--- a/configure.ac	2012-11-07 14:19:08.835373674 +0200
> ++++ b/configure.ac	2012-11-07 14:19:25.481620103 +0200
> +@@ -284,7 +284,8 @@ AC_RUN_IFELSE(
> + 	[AC_MSG_RESULT([yes])
> + 		pgm_unaligned_pointers=yes],
> + 	[AC_MSG_RESULT([no])
> +-		pgm_unaligned_pointers=no])
> ++		pgm_unaligned_pointers=no],
> ++	pgm_unaligned_pointers=yes)

Are we sure that pgm_unaligned_pointers=yes will be valid on all
architectures?

Rather than hardcoding this, I would prefer if it was possible to pass
a variable in the configure script environment to tell the result of
this test. We could then maybe have a chance to upstream the patch.


> diff --git a/package/openpgm/openpgm.mk b/package/openpgm/openpgm.mk
> new file mode 100644
> index 0000000..ed9c041
> --- /dev/null
> +++ b/package/openpgm/openpgm.mk
> @@ -0,0 +1,23 @@
> +#############################################################
> +#
> +# openpgm
> +#
> +#############################################################
> +
> +OPENPGM_VERSION = 5.1.118-1~dfsg
> +OPENPGM_SOURCE = libpgm-$(OPENPGM_VERSION).tar.gz

Strange, the project is called openpgm but the tarball is named libpgm?
Usually, we try to use the upstream name, but here it's unclear if we
should choose libpgm or openpgm. Does the openpgm projects delivers
something else than libpgm?

> +OPENPGM_SITE = http://openpgm.googlecode.com/files/
> +OPENPGM_INSTALL_STAGING = YES
> +OPENPGM_DEPENDENCIES = 

Not needed if it's empty.

You should also add the OPENPGM_LICENSE and OPENPGM_LICENSE_FILES
variables.

> +OPENPGM_AUTORECONF = YES

Since the source code comes as a tarball, it's uncommon to have to do
an autoreconf. Could you add a comment right before this line that
explains why it is needed?

> +OPENPGM_CONF_ENV = ac_cv_file__proc_cpuinfo=yes ac_cv_file__dev_rtc=no \
> +                   ac_cv_file__dev_hpet=no
> +
> +define OPENPGM_EXTRACT_FIX
> +	mv $(@D)/openpgm/pgm/* $(@D)
> +	rm -rf $(@D)/openpgm/pgm/
> +endef
> +
> +OPENPGM_POST_EXTRACT_HOOKS += OPENPGM_EXTRACT_FIX

Have you tried to replace this post extract fix by:

OPENPGM_SUBDIR = openpgm/pgm/

 ?

Thanks,

Thomas
Yann E. MORIN - Feb. 11, 2013, 12:49 p.m.
Thomas, Alexander, All,

On Monday 11 February 2013 13:45:47 Thomas Petazzoni wrote:
> On Mon, 11 Feb 2013 14:30:26 +0200, Alexander Lukichev wrote:
[--SNIP--)
> > +OPENPGM_AUTORECONF = YES
> 
> Since the source code comes as a tarball, it's uncommon to have to do
> an autoreconf. Could you add a comment right before this line that
> explains why it is needed?

Because the patch touches configure.ac.

Regards,
Yann E. MORIN.
Thomas Petazzoni - Feb. 11, 2013, 12:54 p.m.
Dear Yann E. MORIN,

On Mon, 11 Feb 2013 13:49:46 +0100, Yann E. MORIN wrote:

> > Since the source code comes as a tarball, it's uncommon to have to do
> > an autoreconf. Could you add a comment right before this line that
> > explains why it is needed?
> 
> Because the patch touches configure.ac.

Sigh, indeed. Need more sleep, it seems.

Thomas
Alexander Lukichev - Feb. 11, 2013, 1:18 p.m.
Hi, Thomas, All!

On 02/11/2013 02:45 PM, Thomas Petazzoni wrote:
> We no longer want to have patches that contain the package version in
> their filename.
Thanks, I originally based this on 2012.08 release and taught myself by manual (http://www.buildroot.net/downloads/manual/manual.html#patch-policy). I did not closely follow the mailing list. I'll fix this.

> Any reason not to package the most recent version available? Are there
> incompatibilities between 5.1.118 and 5.2.121 that makes 5.2.121
> unusable for zeromq?
I do recall that there were, for zeromq-2.2.0, though I'm not able to tell what went wrong back then. Hence two versions were tried: first the more recent, then 5.1.118-1~dfsg. Modifications in those two patches are the same, so it's no use to have two files. I'll check more closely if zeromq-2.2.0 can be made to work with the recent version of openpgm.  

>> +@@ -284,7 +284,8 @@ AC_RUN_IFELSE(
>> + 	[AC_MSG_RESULT([yes])
>> + 		pgm_unaligned_pointers=yes],
>> + 	[AC_MSG_RESULT([no])
>> +-		pgm_unaligned_pointers=no])
>> ++		pgm_unaligned_pointers=no],
>> ++	pgm_unaligned_pointers=yes)
> 
> Are we sure that pgm_unaligned_pointers=yes will be valid on all
> architectures?
> 
> Rather than hardcoding this, I would prefer if it was possible to pass
> a variable in the configure script environment to tell the result of
> this test.

Is there a way to determine if target architecture has unaligned pointers or aligned pointers?

>> +OPENPGM_VERSION = 5.1.118-1~dfsg
>> +OPENPGM_SOURCE = libpgm-$(OPENPGM_VERSION).tar.gz
> 
> Strange, the project is called openpgm but the tarball is named libpgm?
> Usually, we try to use the upstream name, but here it's unclear if we
> should choose libpgm or openpgm. Does the openpgm projects delivers
> something else than libpgm?

Not as far as I know.

>> +OPENPGM_DEPENDENCIES = 
> Not needed if it's empty.
> You should also add the OPENPGM_LICENSE and OPENPGM_LICENSE_FILES
Thanks, will be fixed.

>> +OPENPGM_AUTORECONF = YES
> 
> Since the source code comes as a tarball, it's uncommon to have to do
> an autoreconf. Could you add a comment right before this line that
> explains why it is needed?
Yes, I will do that. As Yann has mentioned, it's needed because the configure.ac has been patched.

>> +OPENPGM_CONF_ENV = ac_cv_file__proc_cpuinfo=yes ac_cv_file__dev_rtc=no \
>> +                   ac_cv_file__dev_hpet=no

Well, for that matter, these tests too may not be valid for all the target architectures. Could this somehow be determined in advance or?.. OK, I think I know the answer. Is it OK to leave them as is? An alternative would be to try to prompt the user in Kconfig.

>> +OPENPGM_POST_EXTRACT_HOOKS += OPENPGM_EXTRACT_FIX
> Have you tried to replace this post extract fix by:
> OPENPGM_SUBDIR = openpgm/pgm/
>  ?

No. I will try. Thanks.

--
Best regards,
  Alexander Lukichev
Thomas Petazzoni - Feb. 11, 2013, 2:14 p.m.
Dear Alexander Lukichev,

On Mon, 11 Feb 2013 15:18:18 +0200, Alexander Lukichev wrote:

> Thanks, I originally based this on 2012.08 release and taught myself
> by manual
> (http://www.buildroot.net/downloads/manual/manual.html#patch-policy).
> I did not closely follow the mailing list. I'll fix this.

No problem. Note that the manual correctly state that patches should be
named <packagename>-*.patch, and not
<packagename>-<packageversion>-*.patch. That said, the "*" can be
interpreted in a number of ways, so maybe we should add some examples
to clarify what we want in terms of patch naming.

> > Any reason not to package the most recent version available? Are
> > there incompatibilities between 5.1.118 and 5.2.121 that makes
> > 5.2.121 unusable for zeromq?
> I do recall that there were, for zeromq-2.2.0, though I'm not able to
> tell what went wrong back then. Hence two versions were tried: first
> the more recent, then 5.1.118-1~dfsg. Modifications in those two
> patches are the same, so it's no use to have two files. I'll check
> more closely if zeromq-2.2.0 can be made to work with the recent
> version of openpgm.  

Great, thanks.

> >> +@@ -284,7 +284,8 @@ AC_RUN_IFELSE(
> >> + 	[AC_MSG_RESULT([yes])
> >> + 		pgm_unaligned_pointers=yes],
> >> + 	[AC_MSG_RESULT([no])
> >> +-		pgm_unaligned_pointers=no])
> >> ++		pgm_unaligned_pointers=no],
> >> ++	pgm_unaligned_pointers=yes)
> > 
> > Are we sure that pgm_unaligned_pointers=yes will be valid on all
> > architectures?
> > 
> > Rather than hardcoding this, I would prefer if it was possible to
> > pass a variable in the configure script environment to tell the
> > result of this test.
> 
> Is there a way to determine if target architecture has unaligned
> pointers or aligned pointers?

I am wondering whether ac_cv_lbl_unaligned_fail (that we set in
package/Makefile.in) serves the same purpose or not.

> > Strange, the project is called openpgm but the tarball is named
> > libpgm? Usually, we try to use the upstream name, but here it's
> > unclear if we should choose libpgm or openpgm. Does the openpgm
> > projects delivers something else than libpgm?
> 
> Not as far as I know.

Then maybe we want to call the package libpgm ?

> Well, for that matter, these tests too may not be valid for all the
> target architectures. Could this somehow be determined in advance
> or?.. OK, I think I know the answer. Is it OK to leave them as is? An
> alternative would be to try to prompt the user in Kconfig.

The values you're passing seem sane enough to me.

> >> +OPENPGM_POST_EXTRACT_HOOKS += OPENPGM_EXTRACT_FIX
> > Have you tried to replace this post extract fix by:
> > OPENPGM_SUBDIR = openpgm/pgm/
> >  ?
> 
> No. I will try. Thanks.

Thanks!

Thomas
Alexander Lukichev - Feb. 12, 2013, 10:08 a.m.
Hi, Thomas, All!

On 02/11/2013 04:14 PM, Thomas Petazzoni wrote:
>>> unclear if we should choose libpgm or openpgm. Does the openpgm
>>> projects delivers something else than libpgm?
>> Not as far as I know.

Well, actually yes. It's mostly libpgm but there are also bindings for Perl and GStreamer.

> Then maybe we want to call the package libpgm ?
It is referenced from ZeroMQ (in everything, including scripts and documentation) as OpenPGM. I don't know about other packages using it, though.
It is also referenced from inside the package itself (the subdir is openpgm/pgm/ etc). It seems that only the archive and installed library files have libpgm in their names: everything else is named openpgm.
So, I'll do what you and the community advise but I'd rather call it "OpenPGM implementation of libpgm".

--
Best regards,
  Alexander Lukichev

Patch

diff --git a/package/Config.in b/package/Config.in
index 2fad94d..bfaf944 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -524,6 +524,7 @@  source "package/libtorrent/Config.in"
 source "package/libupnp/Config.in"
 source "package/libvncserver/Config.in"
 source "package/nss-mdns/Config.in"
+source "package/openpgm/Config.in"
 source "package/ortp/Config.in"
 source "package/slirp/Config.in"
 source "package/usbredir/Config.in"
diff --git a/package/openpgm/Config.in b/package/openpgm/Config.in
new file mode 100644
index 0000000..e9e5ee6
--- /dev/null
+++ b/package/openpgm/Config.in
@@ -0,0 +1,10 @@ 
+config BR2_PACKAGE_OPENPGM
+	bool "OpenPGM"
+	help
+	  OpenPGM is an open source implementation of the Pragmatic General
+	  Multicast (PGM) specification in RFC 3208 available at www.ietf.org.
+	  PGM is a reliable and scalable multicast protocol that enables
+	  receivers to detect loss, request retransmission of lost data, or
+	  notify an application of unrecoverable loss.
+
+	  http://code.google.com/p/openpgm/
diff --git a/package/openpgm/openpgm-5.1.118-1~dfsg-cross-compile.patch b/package/openpgm/openpgm-5.1.118-1~dfsg-cross-compile.patch
new file mode 100644
index 0000000..2e16c0d
--- /dev/null
+++ b/package/openpgm/openpgm-5.1.118-1~dfsg-cross-compile.patch
@@ -0,0 +1,13 @@ 
+diff -uNrp a/configure.ac b/configure.ac
+--- a/configure.ac	2012-11-07 14:19:08.835373674 +0200
++++ b/configure.ac	2012-11-07 14:19:25.481620103 +0200
+@@ -284,7 +284,8 @@ AC_RUN_IFELSE(
+ 	[AC_MSG_RESULT([yes])
+ 		pgm_unaligned_pointers=yes],
+ 	[AC_MSG_RESULT([no])
+-		pgm_unaligned_pointers=no])
++		pgm_unaligned_pointers=no],
++	pgm_unaligned_pointers=yes)
+ AC_MSG_CHECKING([for intrinsic atomic ops])
+ # AC_PREPROC_IFELSE not always portable
+ AC_COMPILE_IFELSE(
diff --git a/package/openpgm/openpgm-5.2.121~dfsg-cross-compile.patch b/package/openpgm/openpgm-5.2.121~dfsg-cross-compile.patch
new file mode 100644
index 0000000..2e16c0d
--- /dev/null
+++ b/package/openpgm/openpgm-5.2.121~dfsg-cross-compile.patch
@@ -0,0 +1,13 @@ 
+diff -uNrp a/configure.ac b/configure.ac
+--- a/configure.ac	2012-11-07 14:19:08.835373674 +0200
++++ b/configure.ac	2012-11-07 14:19:25.481620103 +0200
+@@ -284,7 +284,8 @@ AC_RUN_IFELSE(
+ 	[AC_MSG_RESULT([yes])
+ 		pgm_unaligned_pointers=yes],
+ 	[AC_MSG_RESULT([no])
+-		pgm_unaligned_pointers=no])
++		pgm_unaligned_pointers=no],
++	pgm_unaligned_pointers=yes)
+ AC_MSG_CHECKING([for intrinsic atomic ops])
+ # AC_PREPROC_IFELSE not always portable
+ AC_COMPILE_IFELSE(
diff --git a/package/openpgm/openpgm.mk b/package/openpgm/openpgm.mk
new file mode 100644
index 0000000..ed9c041
--- /dev/null
+++ b/package/openpgm/openpgm.mk
@@ -0,0 +1,23 @@ 
+#############################################################
+#
+# openpgm
+#
+#############################################################
+
+OPENPGM_VERSION = 5.1.118-1~dfsg
+OPENPGM_SOURCE = libpgm-$(OPENPGM_VERSION).tar.gz
+OPENPGM_SITE = http://openpgm.googlecode.com/files/
+OPENPGM_INSTALL_STAGING = YES
+OPENPGM_DEPENDENCIES = 
+OPENPGM_AUTORECONF = YES
+OPENPGM_CONF_ENV = ac_cv_file__proc_cpuinfo=yes ac_cv_file__dev_rtc=no \
+                   ac_cv_file__dev_hpet=no
+
+define OPENPGM_EXTRACT_FIX
+	mv $(@D)/openpgm/pgm/* $(@D)
+	rm -rf $(@D)/openpgm/pgm/
+endef
+
+OPENPGM_POST_EXTRACT_HOOKS += OPENPGM_EXTRACT_FIX
+
+$(eval $(autotools-package))