[Buildroot] [PATCH 1/5] package/x11r7/xlib_libxshmfence: fix build with glibc 2.27

[Buildroot] [PATCH 1/5] package/x11r7/xlib_libxshmfence: fix build with glibc 2.27

[Romain Naour]

With glibc 2.27 memfd_create() is inside a _GNU_SOURCE guard, so call
AC_USE_SYSTEM_EXTENSIONS to get this defined.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
---
 ...onfigure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch | 30 ++++++++++++++++++++++
 .../x11r7/xlib_libxshmfence/xlib_libxshmfence.mk   |  3 +++
 2 files changed, 33 insertions(+)
 create mode 100644 package/x11r7/xlib_libxshmfence/0001-configure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch

diff --git a/package/x11r7/xlib_libxshmfence/0001-configure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch b/package/x11r7/xlib_libxshmfence/0001-configure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch
new file mode 100644
index 0000000000..f24b1da5dd
--- /dev/null
+++ b/package/x11r7/xlib_libxshmfence/0001-configure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch
@@ -0,0 +1,30 @@
+From 0b550a4e7acf02d3478602848f6afbfcbfb0d4b2 Mon Sep 17 00:00:00 2001
+From: Ross Burton <ross.burton@intel.com>
+Date: Mon, 29 Jan 2018 16:24:36 +0000
+Subject: [PATCH] configure.ac: call AC_USE_SYSTEM_EXTENSIONS
+
+With glibc 2.27 memfd_create() is inside a _GNU_SOURCE guard, so call
+AC_USE_SYSTEM_EXTENSIONS to get this defined.
+
+Signed-off-by: Ross Burton <ross.burton@intel.com>
+Signed-off-by: Romain Naour <romain.naour@gmail.com>
+---
+ configure.ac | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/configure.ac b/configure.ac
+index 55772d0..ed77e6d 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -28,6 +28,8 @@ AC_INIT([libxshmfence], [1.2],
+ AC_CONFIG_SRCDIR([Makefile.am])
+ AC_CONFIG_HEADERS([config.h])
+ 
++AC_USE_SYSTEM_EXTENSIONS
++
+ # Initialize Automake
+ AM_INIT_AUTOMAKE([foreign dist-bzip2])
+ 
+-- 
+2.14.3
+
diff --git a/package/x11r7/xlib_libxshmfence/xlib_libxshmfence.mk b/package/x11r7/xlib_libxshmfence/xlib_libxshmfence.mk
index 3a2f32623a..9686c408c1 100644
--- a/package/x11r7/xlib_libxshmfence/xlib_libxshmfence.mk
+++ b/package/x11r7/xlib_libxshmfence/xlib_libxshmfence.mk
@@ -12,4 +12,7 @@ XLIB_LIBXSHMFENCE_LICENSE_FILES = COPYING
 XLIB_LIBXSHMFENCE_INSTALL_STAGING = YES
 XLIB_LIBXSHMFENCE_DEPENDENCIES = host-pkgconf xproto_xproto
 
+# 0001-configure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch
+XLIB_LIBXSHMFENCE_AUTORECONF = YES
+
 $(eval $(autotools-package))
-- 
2.14.3

[Buildroot] [PATCH 2/5] package/pulseaudio: only define memfd_create() if not already defined

[Romain Naour]

Before glibc version 2.27 there was no wrapper for memfd_create(2).

Signed-off-by: Romain Naour <romain.naour@gmail.com>
---
 ...ers-only-define-memfd_create-if-not-alrea.patch | 64 ++++++++++++++++++++++
 package/pulseaudio/pulseaudio.mk                   |  3 +
 2 files changed, 67 insertions(+)
 create mode 100644 package/pulseaudio/0002-memfd-wrappers-only-define-memfd_create-if-not-alrea.patch

diff --git a/package/pulseaudio/0002-memfd-wrappers-only-define-memfd_create-if-not-alrea.patch b/package/pulseaudio/0002-memfd-wrappers-only-define-memfd_create-if-not-alrea.patch
new file mode 100644
index 0000000000..8f103bf201
--- /dev/null
+++ b/package/pulseaudio/0002-memfd-wrappers-only-define-memfd_create-if-not-alrea.patch
@@ -0,0 +1,64 @@
+From dfb0460fb4743aec047cdf755a660a9ac2d0f3fb Mon Sep 17 00:00:00 2001
+From: Tanu Kaskinen <tanuk@iki.fi>
+Date: Wed, 24 Jan 2018 03:51:49 +0200
+Subject: [PATCH] memfd-wrappers: only define memfd_create() if not already
+ defined
+
+glibc 2.27 is to be released soon, and it will provide memfd_create().
+If glibc provides the function, we must not define it ourselves,
+otherwise building fails due to conflict between the two implementations
+of the same function.
+
+BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=104733
+Signed-off-by: Romain Naour <romain.naour@gmail.com>
+---
+ configure.ac                   | 3 +++
+ src/pulsecore/memfd-wrappers.h | 7 ++++---
+ 2 files changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 0084c86e..0eb44b08 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -610,6 +610,9 @@ AS_IF([test "x$enable_memfd" = "xyes" && test "x$HAVE_MEMFD" = "x0"],
+     [AC_MSG_ERROR([*** Your Linux kernel does not support memfd shared memory.
+                   *** Use linux v3.17 or higher for such a feature.])])
+ 
++AS_IF([test "x$HAVE_MEMFD" = "x1"],
++    AC_CHECK_FUNCS([memfd_create]))
++
+ AC_SUBST(HAVE_MEMFD)
+ AM_CONDITIONAL([HAVE_MEMFD], [test "x$HAVE_MEMFD" = x1])
+ AS_IF([test "x$HAVE_MEMFD" = "x1"], AC_DEFINE([HAVE_MEMFD], 1, [Have memfd shared memory.]))
+diff --git a/src/pulsecore/memfd-wrappers.h b/src/pulsecore/memfd-wrappers.h
+index 3bed9b2b..c7aadfd3 100644
+--- a/src/pulsecore/memfd-wrappers.h
++++ b/src/pulsecore/memfd-wrappers.h
+@@ -20,13 +20,14 @@
+   License along with PulseAudio; if not, see <http://www.gnu.org/licenses/>.
+ ***/
+ 
+-#ifdef HAVE_MEMFD
++#if defined(HAVE_MEMFD) && !defined(HAVE_MEMFD_CREATE)
+ 
+ #include <sys/syscall.h>
+ #include <fcntl.h>
+ 
+ /*
+- * No glibc wrappers exist for memfd_create(2), so provide our own.
++ * Before glibc version 2.27 there was no wrapper for memfd_create(2),
++ * so we have to provide our own.
+  *
+  * Also define memfd fcntl sealing macros. While they are already
+  * defined in the kernel header file <linux/fcntl.h>, that file as
+@@ -63,6 +64,6 @@ static inline int memfd_create(const char *name, unsigned int flags) {
+ #define F_SEAL_WRITE    0x0008  /* prevent writes */
+ #endif
+ 
+-#endif /* HAVE_MEMFD */
++#endif /* HAVE_MEMFD && !HAVE_MEMFD_CREATE */
+ 
+ #endif
+-- 
+2.14.3
+
diff --git a/package/pulseaudio/pulseaudio.mk b/package/pulseaudio/pulseaudio.mk
index 13fcec52a3..f59828d43d 100644
--- a/package/pulseaudio/pulseaudio.mk
+++ b/package/pulseaudio/pulseaudio.mk
@@ -15,6 +15,9 @@ PULSEAUDIO_CONF_OPTS = \
 	--disable-legacy-database-entry-format \
 	--disable-manpages
 
+# 0001-memfd-wrappers-only-define-memfd_create-if-not-alrea.patch
+PULSEAUDIO_AUTORECONF = YES
+
 PULSEAUDIO_DEPENDENCIES = \
 	host-pkgconf libtool libsndfile speex host-intltool \
 	$(if $(BR2_PACKAGE_LIBGLIB2),libglib2) \
-- 
2.14.3

[Buildroot] [PATCH 3/5] package/libraw: rename internal powf64

[Romain Naour]

Starting with Glibc 2.27, powf64() is provided by the C library
and colide with the one defined dy libraw.

Rename internal powf64 to libraw_powf64.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
---
 ...ernal-dcraw_common-rename-internal-powf64.patch | 348 +++++++++++++++++++++
 1 file changed, 348 insertions(+)
 create mode 100644 package/libraw/0003-internal-dcraw_common-rename-internal-powf64.patch

diff --git a/package/libraw/0003-internal-dcraw_common-rename-internal-powf64.patch b/package/libraw/0003-internal-dcraw_common-rename-internal-powf64.patch
new file mode 100644
index 0000000000..ef3b81aa24
--- /dev/null
+++ b/package/libraw/0003-internal-dcraw_common-rename-internal-powf64.patch
@@ -0,0 +1,348 @@
+From 045c57d9d030075575409cf50cd7f6ee635df5c0 Mon Sep 17 00:00:00 2001
+From: Romain Naour <romain.naour@gmail.com>
+Date: Mon, 5 Feb 2018 16:22:39 +0100
+Subject: [PATCH] internal/dcraw_common: rename internal powf64()
+
+Starting with Glibc 2.27, powf64() is provided by the C library
+and colide with the one defined dy libraw.
+
+Rename internal powf64 to libraw_powf64.
+
+Signed-off-by: Romain Naour <romain.naour@gmail.com>
+---
+ internal/dcraw_common.cpp | 98 +++++++++++++++++++++++------------------------
+ 1 file changed, 49 insertions(+), 49 deletions(-)
+
+diff --git a/internal/dcraw_common.cpp b/internal/dcraw_common.cpp
+index 0c7c07a..cf26865 100644
+--- a/internal/dcraw_common.cpp
++++ b/internal/dcraw_common.cpp
+@@ -5537,7 +5537,7 @@ static float powf_lim(float a, float b, float limup)
+ {
+   return (b>limup || b < -limup)?0.f:powf(a,b);
+ }
+-static float powf64(float a, float b)
++static float libraw_powf64(float a, float b)
+ {
+   return powf_lim(a,b,64.f);
+ }
+@@ -5561,7 +5561,7 @@ static float my_roundf(float x) {
+ static float _CanonConvertAperture(ushort in)
+ {
+   if ((in == (ushort)0xffe0) || (in == (ushort)0x7fff)) return 0.0f;
+-  return powf64(2.0, in/64.0);
++  return libraw_powf64(2.0, in/64.0);
+ }
+ 
+ void CLASS setCanonBodyFeatures (unsigned id)
+@@ -5902,21 +5902,21 @@ void CLASS processNikonLensData (uchar *LensData, unsigned len)
+     if (fabsf(imgdata.lens.makernotes.MinFocal) < 1.1f)
+     {
+       if ((imgdata.lens.nikon.NikonLensType ^ (uchar)0x01) || LensData[i + 2])
+-        imgdata.lens.makernotes.MinFocal = 5.0f * powf64(2.0f, (float)LensData[i + 2] / 24.0f);
++        imgdata.lens.makernotes.MinFocal = 5.0f * libraw_powf64(2.0f, (float)LensData[i + 2] / 24.0f);
+       if ((imgdata.lens.nikon.NikonLensType ^ (uchar)0x01) || LensData[i + 3])
+-        imgdata.lens.makernotes.MaxFocal = 5.0f * powf64(2.0f, (float)LensData[i + 3] / 24.0f);
++        imgdata.lens.makernotes.MaxFocal = 5.0f * libraw_powf64(2.0f, (float)LensData[i + 3] / 24.0f);
+       if ((imgdata.lens.nikon.NikonLensType ^ (uchar)0x01) || LensData[i + 4])
+-        imgdata.lens.makernotes.MaxAp4MinFocal = powf64(2.0f, (float)LensData[i + 4] / 24.0f);
++        imgdata.lens.makernotes.MaxAp4MinFocal = libraw_powf64(2.0f, (float)LensData[i + 4] / 24.0f);
+       if ((imgdata.lens.nikon.NikonLensType ^ (uchar)0x01) || LensData[i + 5])
+-        imgdata.lens.makernotes.MaxAp4MaxFocal = powf64(2.0f, (float)LensData[i + 5] / 24.0f);
++        imgdata.lens.makernotes.MaxAp4MaxFocal = libraw_powf64(2.0f, (float)LensData[i + 5] / 24.0f);
+     }
+     imgdata.lens.nikon.NikonMCUVersion = LensData[i + 6];
+     if (i != 2)
+       {
+         if ((LensData[i - 1]) &&
+             (fabsf(imgdata.lens.makernotes.CurFocal) < 1.1f))
+-          imgdata.lens.makernotes.CurFocal = 5.0f * powf64(2.0f, (float)LensData[i - 1] / 24.0f);
+-        if (LensData[i + 7]) imgdata.lens.nikon.NikonEffectiveMaxAp = powf64(2.0f, (float)LensData[i + 7] / 24.0f);
++          imgdata.lens.makernotes.CurFocal = 5.0f * libraw_powf64(2.0f, (float)LensData[i - 1] / 24.0f);
++        if (LensData[i + 7]) imgdata.lens.nikon.NikonEffectiveMaxAp = libraw_powf64(2.0f, (float)LensData[i + 7] / 24.0f);
+       }
+     imgdata.lens.makernotes.LensID =
+       (unsigned long long) LensData[i] << 56 |
+@@ -6088,13 +6088,13 @@ void CLASS PentaxLensInfo (unsigned id, unsigned len)	// tag 0x0207
+ 		if (table_buf[iLensData+9] &&
+ 			(fabs(imgdata.lens.makernotes.CurFocal) < 0.1f))
+ 		  imgdata.lens.makernotes.CurFocal =
+-			10*(table_buf[iLensData+9]>>2) * powf64(4, (table_buf[iLensData+9] & 0x03)-2);
++			10*(table_buf[iLensData+9]>>2) * libraw_powf64(4, (table_buf[iLensData+9] & 0x03)-2);
+ 		if (table_buf[iLensData+10] & 0xf0)
+ 		  imgdata.lens.makernotes.MaxAp4CurFocal =
+-			powf64(2.0f, (float)((table_buf[iLensData+10] & 0xf0) >>4)/4.0f);
++			libraw_powf64(2.0f, (float)((table_buf[iLensData+10] & 0xf0) >>4)/4.0f);
+ 		if (table_buf[iLensData+10] & 0x0f)
+ 		  imgdata.lens.makernotes.MinAp4CurFocal =
+-			powf64(2.0f, (float)((table_buf[iLensData+10] & 0x0f) + 10)/4.0f);
++			libraw_powf64(2.0f, (float)((table_buf[iLensData+10] & 0x0f) + 10)/4.0f);
+ 
+ 		if (iLensData != 12)
+ 		  {
+@@ -6111,14 +6111,14 @@ void CLASS PentaxLensInfo (unsigned id, unsigned len)	// tag 0x0207
+ 			if ((table_buf[iLensData+14] > 1) &&
+ 				(fabs(imgdata.lens.makernotes.MaxAp4CurFocal) < 0.7f))
+ 			  imgdata.lens.makernotes.MaxAp4CurFocal =
+-				powf64(2.0f, (float)((table_buf[iLensData+14] & 0x7f) -1)/32.0f);
++				libraw_powf64(2.0f, (float)((table_buf[iLensData+14] & 0x7f) -1)/32.0f);
+ 		  }
+ 		else if ((id != 0x12e76) &&	// K-5
+ 				 (table_buf[iLensData+15] > 1) &&
+ 				 (fabs(imgdata.lens.makernotes.MaxAp4CurFocal) < 0.7f))
+ 		  {
+ 			imgdata.lens.makernotes.MaxAp4CurFocal =
+-			  powf64(2.0f, (float)((table_buf[iLensData+15] & 0x7f) -1)/32.0f);
++			  libraw_powf64(2.0f, (float)((table_buf[iLensData+15] & 0x7f) -1)/32.0f);
+ 		  }
+ 	  }
+ 	free(table_buf);
+@@ -6525,11 +6525,11 @@ void CLASS process_Sony_0x9050 (uchar * buf, unsigned id)
+     {
+       if (buf[0])
+         imgdata.lens.makernotes.MaxAp4CurFocal =
+-          my_roundf(powf64(2.0f, ((float)SonySubstitution[buf[0]] / 8.0 - 1.06f) / 2.0f)*10.0f) / 10.0f;
++          my_roundf(libraw_powf64(2.0f, ((float)SonySubstitution[buf[0]] / 8.0 - 1.06f) / 2.0f)*10.0f) / 10.0f;
+ 
+       if (buf[1])
+         imgdata.lens.makernotes.MinAp4CurFocal =
+-          my_roundf(powf64(2.0f, ((float)SonySubstitution[buf[1]] / 8.0 - 1.06f) / 2.0f)*10.0f) / 10.0f;
++          my_roundf(libraw_powf64(2.0f, ((float)SonySubstitution[buf[1]] / 8.0 - 1.06f) / 2.0f)*10.0f) / 10.0f;
+     }
+ 
+   if (imgdata.lens.makernotes.CameraMount != LIBRAW_MOUNT_FixedLens)
+@@ -6539,7 +6539,7 @@ void CLASS process_Sony_0x9050 (uchar * buf, unsigned id)
+           lid = SonySubstitution[buf[0x3d]] << 8 |
+             SonySubstitution[buf[0x3c]];
+           imgdata.lens.makernotes.CurAp =
+-            powf64(2.0f, ((float)lid/256.0f - 16.0f) / 2.0f);
++            libraw_powf64(2.0f, ((float)lid/256.0f - 16.0f) / 2.0f);
+         }
+       if (buf[0x105] && (imgdata.lens.makernotes.LensMount != LIBRAW_MOUNT_Canon_EF))
+         imgdata.lens.makernotes.LensMount =
+@@ -6924,7 +6924,7 @@ void CLASS parse_makernote_0xc634(int base, int uptag, unsigned dng_writer)
+           {
+             unsigned char cc;
+             fread(&cc, 1, 1, ifp);
+-            iso_speed = (int)(100.0 * powf64(2.0, (double)(cc) / 12.0 - 5.0));
++            iso_speed = (int)(100.0 * libraw_powf64(2.0, (double)(cc) / 12.0 - 5.0));
+             break;
+           }
+       }
+@@ -6957,7 +6957,7 @@ void CLASS parse_makernote_0xc634(int base, int uptag, unsigned dng_writer)
+           }
+           break;
+         case 0x1002:
+-          imgdata.lens.makernotes.CurAp = powf64(2.0f, getreal(type)/2);
++          imgdata.lens.makernotes.CurAp = libraw_powf64(2.0f, getreal(type)/2);
+           break;
+         case 0x20100201:
+           imgdata.lens.makernotes.LensID =
+@@ -6977,10 +6977,10 @@ void CLASS parse_makernote_0xc634(int base, int uptag, unsigned dng_writer)
+           fread(imgdata.lens.makernotes.Lens, MIN(len,127), 1, ifp);
+           break;
+         case 0x20100205:
+-          imgdata.lens.makernotes.MaxAp4MinFocal = powf64(sqrt(2.0f), get2() / 256.0f);
++          imgdata.lens.makernotes.MaxAp4MinFocal = libraw_powf64(sqrt(2.0f), get2() / 256.0f);
+           break;
+         case 0x20100206:
+-          imgdata.lens.makernotes.MaxAp4MaxFocal = powf64(sqrt(2.0f), get2() / 256.0f);
++          imgdata.lens.makernotes.MaxAp4MaxFocal = libraw_powf64(sqrt(2.0f), get2() / 256.0f);
+           break;
+         case 0x20100207:
+           imgdata.lens.makernotes.MinFocal = (float)get2();
+@@ -6991,7 +6991,7 @@ void CLASS parse_makernote_0xc634(int base, int uptag, unsigned dng_writer)
+             imgdata.lens.makernotes.MaxFocal = imgdata.lens.makernotes.MinFocal;
+           break;
+         case 0x2010020a:
+-          imgdata.lens.makernotes.MaxAp4CurFocal = powf64(sqrt(2.0f), get2() / 256.0f);
++          imgdata.lens.makernotes.MaxAp4CurFocal = libraw_powf64(sqrt(2.0f), get2() / 256.0f);
+           break;
+         case 0x20100301:
+           imgdata.lens.makernotes.TeleconverterID = fgetc(ifp) << 8;
+@@ -7195,7 +7195,7 @@ void CLASS parse_makernote_0xc634(int base, int uptag, unsigned dng_writer)
+                   lid = (((ushort)table_buf[2])<<8) |
+                     ((ushort)table_buf[3]);
+                   imgdata.lens.makernotes.CurAp =
+-                    powf64(2.0f, ((float)lid/8.0f-1.0f)/2.0f);
++                    libraw_powf64(2.0f, ((float)lid/8.0f-1.0f)/2.0f);
+                 }
+               break;
+             case 1536:
+@@ -7669,7 +7669,7 @@ void CLASS parse_makernote (int base, int uptag)
+           }
+           break;
+         case 0x1002:
+-          imgdata.lens.makernotes.CurAp = powf64(2.0f, getreal(type)/2);
++          imgdata.lens.makernotes.CurAp = libraw_powf64(2.0f, getreal(type)/2);
+           break;
+         case 0x20100201:
+           {
+@@ -7694,10 +7694,10 @@ void CLASS parse_makernote (int base, int uptag)
+           fread(imgdata.lens.makernotes.Lens, MIN(len,127), 1, ifp);
+           break;
+         case 0x20100205:
+-          imgdata.lens.makernotes.MaxAp4MinFocal = powf64(sqrt(2.0f), get2() / 256.0f);
++          imgdata.lens.makernotes.MaxAp4MinFocal = libraw_powf64(sqrt(2.0f), get2() / 256.0f);
+           break;
+         case 0x20100206:
+-          imgdata.lens.makernotes.MaxAp4MaxFocal = powf64(sqrt(2.0f), get2() / 256.0f);
++          imgdata.lens.makernotes.MaxAp4MaxFocal = libraw_powf64(sqrt(2.0f), get2() / 256.0f);
+           break;
+         case 0x20100207:
+           imgdata.lens.makernotes.MinFocal = (float)get2();
+@@ -7708,7 +7708,7 @@ void CLASS parse_makernote (int base, int uptag)
+             imgdata.lens.makernotes.MaxFocal = imgdata.lens.makernotes.MinFocal;
+           break;
+         case 0x2010020a:
+-          imgdata.lens.makernotes.MaxAp4CurFocal = powf64(sqrt(2.0f), get2() / 256.0f);
++          imgdata.lens.makernotes.MaxAp4CurFocal = libraw_powf64(sqrt(2.0f), get2() / 256.0f);
+           break;
+         case 0x20100301:
+           imgdata.lens.makernotes.TeleconverterID = fgetc(ifp) << 8;
+@@ -7977,7 +7977,7 @@ void CLASS parse_makernote (int base, int uptag)
+                   lid = (((ushort)table_buf[2])<<8) |
+                     ((ushort)table_buf[3]);
+                   imgdata.lens.makernotes.CurAp =
+-                    powf64(2.0f, ((float)lid/8.0f-1.0f)/2.0f);
++                    libraw_powf64(2.0f, ((float)lid/8.0f-1.0f)/2.0f);
+                 }
+               break;
+             case 1536:
+@@ -8064,19 +8064,19 @@ void CLASS parse_makernote (int base, int uptag)
+       {
+         unsigned char cc;
+         fread(&cc,1,1,ifp);
+-        iso_speed = int(100.0 * powf64(2.0f,float(cc)/12.0-5.0));
++        iso_speed = int(100.0 * libraw_powf64(2.0f,float(cc)/12.0-5.0));
+       }
+     if (tag == 4 && len > 26 && len < 35) {
+       if ((i=(get4(),get2())) != 0x7fff && (!iso_speed || iso_speed == 65535))
+-	iso_speed = 50 * powf64(2.0, i/32.0 - 4);
++	iso_speed = 50 * libraw_powf64(2.0, i/32.0 - 4);
+ #ifdef LIBRAW_LIBRARY_BUILD
+       get4();
+ #else
+       if ((i=(get2(),get2())) != 0x7fff && !aperture)
+-	aperture = powf64(2.0, i/64.0);
++	aperture = libraw_powf64(2.0, i/64.0);
+ #endif
+       if ((i=get2()) != 0xffff && !shutter)
+-	shutter = powf64(2.0, (short) i/-32.0);
++	shutter = libraw_powf64(2.0, (short) i/-32.0);
+       wbi = (get2(),get2());
+       shot_order = (get2(),get2());
+     }
+@@ -8579,7 +8579,7 @@ void CLASS parse_exif (int base)
+         imgdata.lens.Lens[0] = 0;
+       break;
+     case 0x9205:
+-      imgdata.lens.EXIF_MaxAp = powf64(2.0f, (getreal(type) / 2.0f));
++      imgdata.lens.EXIF_MaxAp = libraw_powf64(2.0f, (getreal(type) / 2.0f));
+       break;
+ #endif
+       case 33434:  shutter = getreal(type);		break;
+@@ -8592,10 +8592,10 @@ void CLASS parse_exif (int base)
+       case 36867:
+       case 36868:  get_timestamp(0);			break;
+       case 37377:  if ((expo = -getreal(type)) < 128 && shutter == 0.)
+-          shutter = powf64(2.0, expo);		break;
++          shutter = libraw_powf64(2.0, expo);		break;
+       case 37378:                                       // 0x9202 ApertureValue
+         if ((fabs(ape = getreal(type))<256.0) && (!aperture))
+-          aperture = powf64(2.0, ape/2);
++          aperture = libraw_powf64(2.0, ape/2);
+         break;
+       case 37385:  flash_used = getreal(type);          break;
+       case 37386:  focal_len = getreal(type);		break;
+@@ -9196,7 +9196,7 @@ int CLASS parse_tiff_ifd (int base)
+         imgdata.lens.Lens[0] = 0;
+       break;
+     case 0x9205:
+-				imgdata.lens.EXIF_MaxAp = powf64(2.0f, (getreal(type) / 2.0f));
++				imgdata.lens.EXIF_MaxAp = libraw_powf64(2.0f, (getreal(type) / 2.0f));
+       break;
+ // IB end
+ #endif
+@@ -9970,22 +9970,22 @@ void CLASS parse_ciff (int offset, int length, int depth)
+       thumb_length = len;
+     }
+     if (type == 0x1818) {
+-      shutter = powf64(2.0f, -int_to_float((get4(),get4())));
+-      aperture = powf64(2.0f, int_to_float(get4())/2);
++      shutter = libraw_powf64(2.0f, -int_to_float((get4(),get4())));
++      aperture = libraw_powf64(2.0f, int_to_float(get4())/2);
+ #ifdef LIBRAW_LIBRARY_BUILD
+ 			imgdata.lens.makernotes.CurAp = aperture;
+ #endif
+     }
+     if (type == 0x102a) {
+ 			//      iso_speed = pow (2.0, (get4(),get2())/32.0 - 4) * 50;
+-      iso_speed = powf64(2.0f, ((get2(),get2()) + get2())/32.0f - 5.0f) * 100.0f;
++      iso_speed = libraw_powf64(2.0f, ((get2(),get2()) + get2())/32.0f - 5.0f) * 100.0f;
+ #ifdef LIBRAW_LIBRARY_BUILD
+       aperture  = _CanonConvertAperture((get2(),get2()));
+       imgdata.lens.makernotes.CurAp = aperture;
+ #else
+-      aperture  = powf64(2.0, (get2(),(short)get2())/64.0);
++      aperture  = libraw_powf64(2.0, (get2(),(short)get2())/64.0);
+ #endif
+-      shutter   = powf64(2.0,-((short)get2())/32.0);
++      shutter   = libraw_powf64(2.0,-((short)get2())/32.0);
+       wbi = (get2(),get2());
+       if (wbi > 17) wbi = 0;
+       fseek (ifp, 32, SEEK_CUR);
+@@ -10189,8 +10189,8 @@ void CLASS parse_phase_one (int base)
+       setPhaseOneFeatures(unique_id);
+       break;
+     case 0x0401:
+-      if (type == 4) imgdata.lens.makernotes.CurAp =  powf64(2.0f, (int_to_float(data)/2.0f));
+-      else imgdata.lens.makernotes.CurAp = powf64(2.0f, (getreal(type)/2.0f));
++      if (type == 4) imgdata.lens.makernotes.CurAp =  libraw_powf64(2.0f, (int_to_float(data)/2.0f));
++      else imgdata.lens.makernotes.CurAp = libraw_powf64(2.0f, (getreal(type)/2.0f));
+       break;
+     case 0x0403:
+       if (type == 4) imgdata.lens.makernotes.CurFocal =  int_to_float(data);
+@@ -10204,16 +10204,16 @@ void CLASS parse_phase_one (int base)
+       break;
+     case 0x0414:
+       if (type == 4) {
+-      	imgdata.lens.makernotes.MaxAp4CurFocal = powf64(2.0f, (int_to_float(data)/2.0f));
++      	imgdata.lens.makernotes.MaxAp4CurFocal = libraw_powf64(2.0f, (int_to_float(data)/2.0f));
+       } else {
+-        imgdata.lens.makernotes.MaxAp4CurFocal = powf64(2.0f, (getreal(type) / 2.0f));
++        imgdata.lens.makernotes.MaxAp4CurFocal = libraw_powf64(2.0f, (getreal(type) / 2.0f));
+       }
+       break;
+     case 0x0415:
+       if (type == 4) {
+-      	imgdata.lens.makernotes.MinAp4CurFocal = powf64(2.0f, (int_to_float(data)/2.0f));
++      	imgdata.lens.makernotes.MinAp4CurFocal = libraw_powf64(2.0f, (int_to_float(data)/2.0f));
+       } else {
+-        imgdata.lens.makernotes.MinAp4CurFocal = powf64(2.0f, (getreal(type) / 2.0f));
++        imgdata.lens.makernotes.MinAp4CurFocal = libraw_powf64(2.0f, (getreal(type) / 2.0f));
+       }
+       break;
+     case 0x0416:
+@@ -12119,15 +12119,15 @@ void CLASS identify()
+       case 18: iso_speed = 320; break;
+       case 19: iso_speed = 400; break;
+     }
+-    shutter = powf64(2.0f, (((float)get4())/8.0f)) / 16000.0f;
++    shutter = libraw_powf64(2.0f, (((float)get4())/8.0f)) / 16000.0f;
+     FORC4 cam_mul[c ^ (c >> 1)] = get4();
+     fseek (ifp, 88, SEEK_SET);
+-    aperture = powf64(2.0f, ((float)get4())/16.0f);
++    aperture = libraw_powf64(2.0f, ((float)get4())/16.0f);
+     fseek (ifp, 112, SEEK_SET);
+     focal_len = get4();
+ #ifdef LIBRAW_LIBRARY_BUILD
+     fseek (ifp, 104, SEEK_SET);
+-    imgdata.lens.makernotes.MaxAp4CurFocal = powf64(2.0f, ((float)get4())/16.0f);
++    imgdata.lens.makernotes.MaxAp4CurFocal = libraw_powf64(2.0f, ((float)get4())/16.0f);
+     fseek (ifp, 124, SEEK_SET);
+     fread(imgdata.lens.makernotes.Lens, 32, 1, ifp);
+     imgdata.lens.makernotes.CameraMount = LIBRAW_MOUNT_Contax_N;
+-- 
+2.14.3
+
-- 
2.14.3

[Buildroot] [PATCH 4/5] package/glibc: remove GLIBC_SRC_SUBDIR

[Romain Naour]

GLIBC_SRC_SUBDIR was needed when Buildroot supported
eglibc which stored all sources in a sub-directory.
It was not removed by the commit removing eglibc support [1].

[1] 500de2598a4902a0e9ec53f7b475046ff17c6681

Signed-off-by: Romain Naour <romain.naour@gmail.com>
---
 package/glibc/glibc.mk | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
index fd79d84f15..cf4bdec065 100644
--- a/package/glibc/glibc.mk
+++ b/package/glibc/glibc.mk
@@ -20,10 +20,8 @@ GLIBC_VERSION = glibc-2.26-107-g73a92363619e52c458146e903dfb9b1ba823aa40
 GLIBC_SITE = $(call github,bminor,glibc,$(GLIBC_VERSION))
 endif
 
-GLIBC_SRC_SUBDIR = .
-
 GLIBC_LICENSE = GPL-2.0+ (programs), LGPL-2.1+, BSD-3-Clause, MIT (library)
-GLIBC_LICENSE_FILES = $(addprefix $(GLIBC_SRC_SUBDIR)/,COPYING COPYING.LIB LICENSES)
+GLIBC_LICENSE_FILES = COPYING COPYING.LIB LICENSES
 
 # glibc is part of the toolchain so disable the toolchain dependency
 GLIBC_ADD_TOOLCHAIN_DEPENDENCY = NO
@@ -86,7 +84,7 @@ define GLIBC_CONFIGURE_CMDS
 		$(TARGET_CONFIGURE_OPTS) \
 		CFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" CPPFLAGS="" \
 		CXXFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" \
-		$(SHELL) $(@D)/$(GLIBC_SRC_SUBDIR)/configure \
+		$(SHELL) $(@D)/configure \
 		ac_cv_path_BASH_SHELL=/bin/bash \
 		libc_cv_forced_unwind=yes \
 		libc_cv_ssp=no \
-- 
2.14.3

[Buildroot] [PATCH 4/5] package/glibc: remove GLIBC_SRC_SUBDIR

[Yann E. MORIN]

Romain, All,

On 2018-02-05 21:57 +0100, Romain Naour spake thusly:
> GLIBC_SRC_SUBDIR was needed when Buildroot supported
> eglibc which stored all sources in a sub-directory.
> It was not removed by the commit removing eglibc support [1].
> 
> [1] 500de2598a4902a0e9ec53f7b475046ff17c6681
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>

Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

This can also be applied to master, probably...

Regards,
Yann E. MORIN.

> ---
>  package/glibc/glibc.mk | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
> index fd79d84f15..cf4bdec065 100644
> --- a/package/glibc/glibc.mk
> +++ b/package/glibc/glibc.mk
> @@ -20,10 +20,8 @@ GLIBC_VERSION = glibc-2.26-107-g73a92363619e52c458146e903dfb9b1ba823aa40
>  GLIBC_SITE = $(call github,bminor,glibc,$(GLIBC_VERSION))
>  endif
>  
> -GLIBC_SRC_SUBDIR = .
> -
>  GLIBC_LICENSE = GPL-2.0+ (programs), LGPL-2.1+, BSD-3-Clause, MIT (library)
> -GLIBC_LICENSE_FILES = $(addprefix $(GLIBC_SRC_SUBDIR)/,COPYING COPYING.LIB LICENSES)
> +GLIBC_LICENSE_FILES = COPYING COPYING.LIB LICENSES
>  
>  # glibc is part of the toolchain so disable the toolchain dependency
>  GLIBC_ADD_TOOLCHAIN_DEPENDENCY = NO
> @@ -86,7 +84,7 @@ define GLIBC_CONFIGURE_CMDS
>  		$(TARGET_CONFIGURE_OPTS) \
>  		CFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" CPPFLAGS="" \
>  		CXXFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" \
> -		$(SHELL) $(@D)/$(GLIBC_SRC_SUBDIR)/configure \
> +		$(SHELL) $(@D)/configure \
>  		ac_cv_path_BASH_SHELL=/bin/bash \
>  		libc_cv_forced_unwind=yes \
>  		libc_cv_ssp=no \
> -- 
> 2.14.3
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Romain Naour]

See: https://sourceware.org/ml/libc-announce/2018/msg00000.html
https://sourceware.org/glibc/wiki/Release/2.27

Add hash files

Signed-off-by: Romain Naour <romain.naour@gmail.com>
---
 package/glibc/glibc.hash | 6 +++++-
 package/glibc/glibc.mk   | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/package/glibc/glibc.hash b/package/glibc/glibc.hash
index f3a6577d2a..86d3bb56dd 100644
--- a/package/glibc/glibc.hash
+++ b/package/glibc/glibc.hash
@@ -1,4 +1,8 @@
 # Locally calculated (fetched from Github)
-sha256  0766875391224153502c5542a71b6e46db53b44691078b3130e1a0df41586430     glibc-glibc-2.26-107-g73a92363619e52c458146e903dfb9b1ba823aa40.tar.gz
+sha256  a74489d14f4017bee6a6c6fe76f1de0dbf7d66c8695116de5aadd141c4757892     glibc-glibc-2.27.tar.gz
 # Locally calculated (fetched from Github)
 sha256  5aa9adeac09727db0b8a52794186563771e74d70410e9fd86431e339953fd4bb     glibc-arc-2017.09-release.tar.gz
+
+sha256  8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643  COPYING
+sha256  dc626520dcd53a22f727af3ee42c770e56c97a64fe3adb063799d8ab032fe551  COPYING.LIB
+sha256  61abdd6930c9c599062d89e916b3e7968783879b6be0ee1c6229dd6169def431  LICENSES
diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
index cf4bdec065..b674191b22 100644
--- a/package/glibc/glibc.mk
+++ b/package/glibc/glibc.mk
@@ -10,7 +10,7 @@ GLIBC_SITE = $(call github,foss-for-synopsys-dwc-arc-processors,glibc,$(GLIBC_VE
 else
 # Generate version string using:
 #   git describe --match 'glibc-*' --abbrev=40 origin/release/MAJOR.MINOR/master
-GLIBC_VERSION = glibc-2.26-107-g73a92363619e52c458146e903dfb9b1ba823aa40
+GLIBC_VERSION = glibc-2.27
 # Upstream doesn't officially provide an https download link.
 # There is one (https://sourceware.org/git/glibc.git) but it's not reliable,
 # sometimes the connection times out. So use an unofficial github mirror.
-- 
2.14.3

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Baruch Siach]

Hi Romain,

On Mon, Feb 05, 2018 at 09:57:16PM +0100, Romain Naour wrote:
> See: https://sourceware.org/ml/libc-announce/2018/msg00000.html
> https://sourceware.org/glibc/wiki/Release/2.27

Note that this is a security bump fixing CVE-2017-1000408, CVE-2017-1000409, 
CVE-2017-16997, CVE-2018-1000001, and CVE-2018-6485.

> Add hash files

You mean license files hash, right?

baruch

> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> ---
>  package/glibc/glibc.hash | 6 +++++-
>  package/glibc/glibc.mk   | 2 +-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/package/glibc/glibc.hash b/package/glibc/glibc.hash
> index f3a6577d2a..86d3bb56dd 100644
> --- a/package/glibc/glibc.hash
> +++ b/package/glibc/glibc.hash
> @@ -1,4 +1,8 @@
>  # Locally calculated (fetched from Github)
> -sha256  0766875391224153502c5542a71b6e46db53b44691078b3130e1a0df41586430     glibc-glibc-2.26-107-g73a92363619e52c458146e903dfb9b1ba823aa40.tar.gz
> +sha256  a74489d14f4017bee6a6c6fe76f1de0dbf7d66c8695116de5aadd141c4757892     glibc-glibc-2.27.tar.gz
>  # Locally calculated (fetched from Github)
>  sha256  5aa9adeac09727db0b8a52794186563771e74d70410e9fd86431e339953fd4bb     glibc-arc-2017.09-release.tar.gz
> +
> +sha256  8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643  COPYING
> +sha256  dc626520dcd53a22f727af3ee42c770e56c97a64fe3adb063799d8ab032fe551  COPYING.LIB
> +sha256  61abdd6930c9c599062d89e916b3e7968783879b6be0ee1c6229dd6169def431  LICENSES
> diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
> index cf4bdec065..b674191b22 100644
> --- a/package/glibc/glibc.mk
> +++ b/package/glibc/glibc.mk
> @@ -10,7 +10,7 @@ GLIBC_SITE = $(call github,foss-for-synopsys-dwc-arc-processors,glibc,$(GLIBC_VE
>  else
>  # Generate version string using:
>  #   git describe --match 'glibc-*' --abbrev=40 origin/release/MAJOR.MINOR/master
> -GLIBC_VERSION = glibc-2.26-107-g73a92363619e52c458146e903dfb9b1ba823aa40
> +GLIBC_VERSION = glibc-2.27
>  # Upstream doesn't officially provide an https download link.
>  # There is one (https://sourceware.org/git/glibc.git) but it's not reliable,
>  # sometimes the connection times out. So use an unofficial github mirror.

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Romain Naour]

Hi Baruch,

Le 05/02/2018 ? 22:01, Baruch Siach a ?crit?:
> Hi Romain,
> 
> On Mon, Feb 05, 2018 at 09:57:16PM +0100, Romain Naour wrote:
>> See: https://sourceware.org/ml/libc-announce/2018/msg00000.html
>> https://sourceware.org/glibc/wiki/Release/2.27
> 
> Note that this is a security bump fixing CVE-2017-1000408, CVE-2017-1000409, 
> CVE-2017-16997, CVE-2018-1000001, and CVE-2018-6485.

Ok thanks, I'll add them.

> 
>> Add hash files
> 
> You mean license files hash, right?

Yes Indeed.

Best regards,
Romain

> 
> baruch
> 
>> Signed-off-by: Romain Naour <romain.naour@gmail.com>
>> ---
>>  package/glibc/glibc.hash | 6 +++++-
>>  package/glibc/glibc.mk   | 2 +-
>>  2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/package/glibc/glibc.hash b/package/glibc/glibc.hash
>> index f3a6577d2a..86d3bb56dd 100644
>> --- a/package/glibc/glibc.hash
>> +++ b/package/glibc/glibc.hash
>> @@ -1,4 +1,8 @@
>>  # Locally calculated (fetched from Github)
>> -sha256  0766875391224153502c5542a71b6e46db53b44691078b3130e1a0df41586430     glibc-glibc-2.26-107-g73a92363619e52c458146e903dfb9b1ba823aa40.tar.gz
>> +sha256  a74489d14f4017bee6a6c6fe76f1de0dbf7d66c8695116de5aadd141c4757892     glibc-glibc-2.27.tar.gz
>>  # Locally calculated (fetched from Github)
>>  sha256  5aa9adeac09727db0b8a52794186563771e74d70410e9fd86431e339953fd4bb     glibc-arc-2017.09-release.tar.gz
>> +
>> +sha256  8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643  COPYING
>> +sha256  dc626520dcd53a22f727af3ee42c770e56c97a64fe3adb063799d8ab032fe551  COPYING.LIB
>> +sha256  61abdd6930c9c599062d89e916b3e7968783879b6be0ee1c6229dd6169def431  LICENSES
>> diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
>> index cf4bdec065..b674191b22 100644
>> --- a/package/glibc/glibc.mk
>> +++ b/package/glibc/glibc.mk
>> @@ -10,7 +10,7 @@ GLIBC_SITE = $(call github,foss-for-synopsys-dwc-arc-processors,glibc,$(GLIBC_VE
>>  else
>>  # Generate version string using:
>>  #   git describe --match 'glibc-*' --abbrev=40 origin/release/MAJOR.MINOR/master
>> -GLIBC_VERSION = glibc-2.26-107-g73a92363619e52c458146e903dfb9b1ba823aa40
>> +GLIBC_VERSION = glibc-2.27
>>  # Upstream doesn't officially provide an https download link.
>>  # There is one (https://sourceware.org/git/glibc.git) but it's not reliable,
>>  # sometimes the connection times out. So use an unofficial github mirror.
> 

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Yann E. MORIN]

Baruch, All,

On 2018-02-05 23:01 +0200, Baruch Siach spake thusly:
> On Mon, Feb 05, 2018 at 09:57:16PM +0100, Romain Naour wrote:
> > See: https://sourceware.org/ml/libc-announce/2018/msg00000.html
> > https://sourceware.org/glibc/wiki/Release/2.27
> Note that this is a security bump fixing CVE-2017-1000408, CVE-2017-1000409, 
> CVE-2017-16997, CVE-2018-1000001, and CVE-2018-6485.

There are 10 CVE listed in the release annoucement mail, but you list
only five here. Why only those?

Do we want to list all the CVEs fixed in a release? And if we don't list
all, why do we even list only a subset?

I don't think we should, especially since the release mail is linked to
the commit log and has all the details.

Regards,
Yann E. MORIN.

> > Add hash files
> 
> You mean license files hash, right?
> 
> baruch
> 
> > Signed-off-by: Romain Naour <romain.naour@gmail.com>
> > ---
> >  package/glibc/glibc.hash | 6 +++++-
> >  package/glibc/glibc.mk   | 2 +-
> >  2 files changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/package/glibc/glibc.hash b/package/glibc/glibc.hash
> > index f3a6577d2a..86d3bb56dd 100644
> > --- a/package/glibc/glibc.hash
> > +++ b/package/glibc/glibc.hash
> > @@ -1,4 +1,8 @@
> >  # Locally calculated (fetched from Github)
> > -sha256  0766875391224153502c5542a71b6e46db53b44691078b3130e1a0df41586430     glibc-glibc-2.26-107-g73a92363619e52c458146e903dfb9b1ba823aa40.tar.gz
> > +sha256  a74489d14f4017bee6a6c6fe76f1de0dbf7d66c8695116de5aadd141c4757892     glibc-glibc-2.27.tar.gz
> >  # Locally calculated (fetched from Github)
> >  sha256  5aa9adeac09727db0b8a52794186563771e74d70410e9fd86431e339953fd4bb     glibc-arc-2017.09-release.tar.gz
> > +
> > +sha256  8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643  COPYING
> > +sha256  dc626520dcd53a22f727af3ee42c770e56c97a64fe3adb063799d8ab032fe551  COPYING.LIB
> > +sha256  61abdd6930c9c599062d89e916b3e7968783879b6be0ee1c6229dd6169def431  LICENSES
> > diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
> > index cf4bdec065..b674191b22 100644
> > --- a/package/glibc/glibc.mk
> > +++ b/package/glibc/glibc.mk
> > @@ -10,7 +10,7 @@ GLIBC_SITE = $(call github,foss-for-synopsys-dwc-arc-processors,glibc,$(GLIBC_VE
> >  else
> >  # Generate version string using:
> >  #   git describe --match 'glibc-*' --abbrev=40 origin/release/MAJOR.MINOR/master
> > -GLIBC_VERSION = glibc-2.26-107-g73a92363619e52c458146e903dfb9b1ba823aa40
> > +GLIBC_VERSION = glibc-2.27
> >  # Upstream doesn't officially provide an https download link.
> >  # There is one (https://sourceware.org/git/glibc.git) but it's not reliable,
> >  # sometimes the connection times out. So use an unofficial github mirror.
> 
> -- 
>      http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
>    - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Baruch, All,
 > On 2018-02-05 23:01 +0200, Baruch Siach spake thusly:
 >> On Mon, Feb 05, 2018 at 09:57:16PM +0100, Romain Naour wrote:
 >> > See: https://sourceware.org/ml/libc-announce/2018/msg00000.html
 >> > https://sourceware.org/glibc/wiki/Release/2.27
 >> Note that this is a security bump fixing CVE-2017-1000408, CVE-2017-1000409, 
 >> CVE-2017-16997, CVE-2018-1000001, and CVE-2018-6485.

 > There are 10 CVE listed in the release annoucement mail, but you list
 > only five here. Why only those?

 > Do we want to list all the CVEs fixed in a release? And if we don't list
 > all, why do we even list only a subset?

 > I don't think we should, especially since the release mail is linked to
 > the commit log and has all the details.

For security bumps we normally DO list the CVEs for ease of use, E.G.:

commit d52cd750c762c78ebcf8623fab8a9c43c9419625
Author: Peter Korsgaard <peter@korsgaard.com>
Date:   Sun Jan 28 20:23:02 2018 +0100

    wireshark: security bump to version 2.2.12

    Fixes the following security issues:

    CVE-2017-17997: MRDISC dissector crash
    https://www.wireshark.org/security/wnpa-sec-2018-02.html

    CVE-2018-5334: IxVeriWave file parser crash
    https://www.wireshark.org/security/wnpa-sec-2018-03.html

    CVE-2018-5335: WCP dissector crash
    https://www.wireshark.org/security/wnpa-sec-2018-04.html

    CVE-2018-5336: Multiple dissectors could crash
    https://www.wireshark.org/security/wnpa-sec-2018-01.html

    For more information, see the release notes:
    https://www.wireshark.org/docs/relnotes/wireshark-2.2.12.html

    While we are at it, also add as hash for license file.

    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>


So I prefer to do that as well here.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Baruch Siach]

Hi Yann,

On Mon, Feb 05, 2018 at 10:41:57PM +0100, Yann E. MORIN wrote:
> On 2018-02-05 23:01 +0200, Baruch Siach spake thusly:
> > On Mon, Feb 05, 2018 at 09:57:16PM +0100, Romain Naour wrote:
> > > See: https://sourceware.org/ml/libc-announce/2018/msg00000.html
> > > https://sourceware.org/glibc/wiki/Release/2.27
> > Note that this is a security bump fixing CVE-2017-1000408, CVE-2017-1000409, 
> > CVE-2017-16997, CVE-2018-1000001, and CVE-2018-6485.
> 
> There are 10 CVE listed in the release annoucement mail, but you list
> only five here. Why only those?

Because all other CVEs were fixed in the 2.26 stable branch that we currently 
use. See 971ed9653e (glibc: security bump to the latest 2.26 branch).

> Do we want to list all the CVEs fixed in a release? And if we don't list
> all, why do we even list only a subset?

We do list all. See above.

> I don't think we should, especially since the release mail is linked to
> the commit log and has all the details.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Arnout Vandecappelle]

On 05-02-18 22:01, Baruch Siach wrote:
> Hi Romain,
> 
> On Mon, Feb 05, 2018 at 09:57:16PM +0100, Romain Naour wrote:
>> See: https://sourceware.org/ml/libc-announce/2018/msg00000.html
>> https://sourceware.org/glibc/wiki/Release/2.27
> Note that this is a security bump fixing CVE-2017-1000408, CVE-2017-1000409, 
> CVE-2017-16997, CVE-2018-1000001, and CVE-2018-6485.

 Even though this release fixes a number of CVEs, I wouldn't call it a security
bump. Indeed, it also makes a number of potentially breaking feature updates,
cfr. the memfd_create() change.

 So, I would indeed mention the CVE numbers in the commit message, but not put
"security bump" in the title so that it doesn't mindlessly get applied to LTS
branches.

 Now, in this particular case we made enough noise about it that it really
doesn't matter what goes into the subject line :-) However I think it's good to
converge on some conventions on how to tag LTS things.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Baruch Siach]

Hi Arnout,

On Tue, Feb 06, 2018 at 09:18:38AM +0100, Arnout Vandecappelle wrote:
> On 05-02-18 22:01, Baruch Siach wrote:
> > On Mon, Feb 05, 2018 at 09:57:16PM +0100, Romain Naour wrote:
> >> See: https://sourceware.org/ml/libc-announce/2018/msg00000.html
> >> https://sourceware.org/glibc/wiki/Release/2.27
> > Note that this is a security bump fixing CVE-2017-1000408, CVE-2017-1000409, 
> > CVE-2017-16997, CVE-2018-1000001, and CVE-2018-6485.
> 
>  Even though this release fixes a number of CVEs, I wouldn't call it a security
> bump. Indeed, it also makes a number of potentially breaking feature updates,
> cfr. the memfd_create() change.
> 
>  So, I would indeed mention the CVE numbers in the commit message, but not put
> "security bump" in the title so that it doesn't mindlessly get applied to LTS
> branches.
> 
>  Now, in this particular case we made enough noise about it that it really
> doesn't matter what goes into the subject line :-) However I think it's good to
> converge on some conventions on how to tag LTS things.

I agree that this bump might not be suitable for the maintenance branches. But 
I think we should consider it for the master branch, especially since we are 
still early in the -rc cycle.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Arnout Vandecappelle]

On 06-02-18 11:50, Baruch Siach wrote:
> Hi Arnout,
> 
> On Tue, Feb 06, 2018 at 09:18:38AM +0100, Arnout Vandecappelle wrote:
>> On 05-02-18 22:01, Baruch Siach wrote:
>>> On Mon, Feb 05, 2018 at 09:57:16PM +0100, Romain Naour wrote:
>>>> See: https://sourceware.org/ml/libc-announce/2018/msg00000.html
>>>> https://sourceware.org/glibc/wiki/Release/2.27
>>> Note that this is a security bump fixing CVE-2017-1000408, CVE-2017-1000409, 
>>> CVE-2017-16997, CVE-2018-1000001, and CVE-2018-6485.
>>
>>  Even though this release fixes a number of CVEs, I wouldn't call it a security
>> bump. Indeed, it also makes a number of potentially breaking feature updates,
>> cfr. the memfd_create() change.
>>
>>  So, I would indeed mention the CVE numbers in the commit message, but not put
>> "security bump" in the title so that it doesn't mindlessly get applied to LTS
>> branches.
>>
>>  Now, in this particular case we made enough noise about it that it really
>> doesn't matter what goes into the subject line :-) However I think it's good to
>> converge on some conventions on how to tag LTS things.
> 
> I agree that this bump might not be suitable for the maintenance branches. But 
> I think we should consider it for the master branch, especially since we are 
> still early in the -rc cycle.

 After a bit of discussion at the BR developer meeting: if it fixes CVEs, it
should be called a "security bump". So ignore my earlier comment. It something
that should be backported to LTS.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Peter Korsgaard]

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

 > Hi Arnout,
 > On Tue, Feb 06, 2018 at 09:18:38AM +0100, Arnout Vandecappelle wrote:
 >> On 05-02-18 22:01, Baruch Siach wrote:
 >> > On Mon, Feb 05, 2018 at 09:57:16PM +0100, Romain Naour wrote:
 >> >> See: https://sourceware.org/ml/libc-announce/2018/msg00000.html
 >> >> https://sourceware.org/glibc/wiki/Release/2.27
 >> > Note that this is a security bump fixing CVE-2017-1000408, CVE-2017-1000409, 
 >> > CVE-2017-16997, CVE-2018-1000001, and CVE-2018-6485.
 >> 
 >> Even though this release fixes a number of CVEs, I wouldn't call it a security
 >> bump. Indeed, it also makes a number of potentially breaking feature updates,
 >> cfr. the memfd_create() change.
 >> 
 >> So, I would indeed mention the CVE numbers in the commit message, but not put
 >> "security bump" in the title so that it doesn't mindlessly get applied to LTS
 >> branches.
 >> 
 >> Now, in this particular case we made enough noise about it that it really
 >> doesn't matter what goes into the subject line :-) However I think it's good to
 >> converge on some conventions on how to tag LTS things.

 > I agree that this bump might not be suitable for the maintenance branches. But 
 > I think we should consider it for the master branch, especially since we are 
 > still early in the -rc cycle.

Possibly, yes. Lets see how much blows up on next. Do you know if (some
of) these issues are also fixed on the 2.26 branch?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Baruch Siach]

Hi Peter,

On Tue, Feb 06, 2018 at 02:44:36PM +0100, Peter Korsgaard wrote:
> >>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
> 
>  > On Tue, Feb 06, 2018 at 09:18:38AM +0100, Arnout Vandecappelle wrote:
>  >> On 05-02-18 22:01, Baruch Siach wrote:
>  >> > On Mon, Feb 05, 2018 at 09:57:16PM +0100, Romain Naour wrote:
>  >> >> See: https://sourceware.org/ml/libc-announce/2018/msg00000.html
>  >> >> https://sourceware.org/glibc/wiki/Release/2.27
>  >> > Note that this is a security bump fixing CVE-2017-1000408, CVE-2017-1000409, 
>  >> > CVE-2017-16997, CVE-2018-1000001, and CVE-2018-6485.
>  >> 
>  >> Even though this release fixes a number of CVEs, I wouldn't call it a security
>  >> bump. Indeed, it also makes a number of potentially breaking feature updates,
>  >> cfr. the memfd_create() change.
>  >> 
>  >> So, I would indeed mention the CVE numbers in the commit message, but not put
>  >> "security bump" in the title so that it doesn't mindlessly get applied to LTS
>  >> branches.
>  >> 
>  >> Now, in this particular case we made enough noise about it that it really
>  >> doesn't matter what goes into the subject line :-) However I think it's good to
>  >> converge on some conventions on how to tag LTS things.
> 
>  > I agree that this bump might not be suitable for the maintenance branches. But 
>  > I think we should consider it for the master branch, especially since we are 
>  > still early in the -rc cycle.
> 
> Possibly, yes. Lets see how much blows up on next. Do you know if (some
> of) these issues are also fixed on the 2.26 branch?

As far as I know all these issues are fixed in the 2.26 stable branch. See the 
NEWS file in that branch.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Peter Korsgaard]

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

Hi,

 >> Possibly, yes. Lets see how much blows up on next. Do you know if (some
 >> of) these issues are also fixed on the 2.26 branch?

 > As far as I know all these issues are fixed in the 2.26 stable branch. See the 
 > NEWS file in that branch.

Ok, but only when we bump to the latest version on the 2.26 branch
- E.G.:

git diff 73a92363619e52c458146e903dfb9b1ba823aa40.. -- NEWS

  CVE-2017-1000408: Incorrect array size computation in _dl_init_paths leads
  to the allocation of too much memory.  (This is not a security bug per se,
  it is mentioned here only because of the CVE assignment.)  Reported by
  Qualys.

  CVE-2017-1000409: Buffer overflow in _dl_init_paths due to miscomputation
  of the number of search path components.  (This is not a security
  vulnerability per se because no trust boundary is crossed if the fix for
  CVE-2017-1000366 has been applied, but it is mentioned here only because
  of the CVE assignment.)  Reported by Qualys.

  CVE-2017-16997: Incorrect handling of RPATH or RUNPATH containing $ORIGIN
  for AT_SECURE or SUID binaries could be used to load libraries from the
  current directory.

  CVE-2018-1000001: Buffer underflow in realpath function when getcwd function
  succeeds without returning an absolute path due to unexpected behaviour
  of the Linux kernel getcwd syscall.  Reported by halfdog.

I don't see any reference to CVE-2018-6485 though.

I'll send a patch to bump the version.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 5/5] package/glibc: bump to 2.27

[Baruch Siach]

Hi Peter,

On Tue, Feb 06, 2018 at 03:41:47PM +0100, Peter Korsgaard wrote:
> >>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
> 
> Hi,
> 
>  >> Possibly, yes. Lets see how much blows up on next. Do you know if (some
>  >> of) these issues are also fixed on the 2.26 branch?
> 
>  > As far as I know all these issues are fixed in the 2.26 stable branch. See the 
>  > NEWS file in that branch.
> 
> Ok, but only when we bump to the latest version on the 2.26 branch
> - E.G.:
> 
> git diff 73a92363619e52c458146e903dfb9b1ba823aa40.. -- NEWS
> 
>   CVE-2017-1000408: Incorrect array size computation in _dl_init_paths leads
>   to the allocation of too much memory.  (This is not a security bug per se,
>   it is mentioned here only because of the CVE assignment.)  Reported by
>   Qualys.
> 
>   CVE-2017-1000409: Buffer overflow in _dl_init_paths due to miscomputation
>   of the number of search path components.  (This is not a security
>   vulnerability per se because no trust boundary is crossed if the fix for
>   CVE-2017-1000366 has been applied, but it is mentioned here only because
>   of the CVE assignment.)  Reported by Qualys.
> 
>   CVE-2017-16997: Incorrect handling of RPATH or RUNPATH containing $ORIGIN
>   for AT_SECURE or SUID binaries could be used to load libraries from the
>   current directory.
> 
>   CVE-2018-1000001: Buffer underflow in realpath function when getcwd function
>   succeeds without returning an absolute path due to unexpected behaviour
>   of the Linux kernel getcwd syscall.  Reported by halfdog.
> 
> I don't see any reference to CVE-2018-6485 though.

Right. CVE-2018-6485 and CVE-2018-6551 are fixed in 2.27, but not (yet?) in 
the 2.26 release branch.

> I'll send a patch to bump the version.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[Buildroot] [PATCH 1/5] package/x11r7/xlib_libxshmfence: fix build with glibc 2.27

[Yann E. MORIN]

Romain, All,

On 2018-02-05 21:57 +0100, Romain Naour spake thusly:
> With glibc 2.27 memfd_create() is inside a _GNU_SOURCE guard, so call
> AC_USE_SYSTEM_EXTENSIONS to get this defined.
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> ---
>  ...onfigure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch | 30 ++++++++++++++++++++++
>  .../x11r7/xlib_libxshmfence/xlib_libxshmfence.mk   |  3 +++
>  2 files changed, 33 insertions(+)
>  create mode 100644 package/x11r7/xlib_libxshmfence/0001-configure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch
> 
> diff --git a/package/x11r7/xlib_libxshmfence/0001-configure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch b/package/x11r7/xlib_libxshmfence/0001-configure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch
> new file mode 100644
> index 0000000000..f24b1da5dd
> --- /dev/null
> +++ b/package/x11r7/xlib_libxshmfence/0001-configure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch
> @@ -0,0 +1,30 @@
> +From 0b550a4e7acf02d3478602848f6afbfcbfb0d4b2 Mon Sep 17 00:00:00 2001
> +From: Ross Burton <ross.burton@intel.com>
> +Date: Mon, 29 Jan 2018 16:24:36 +0000
> +Subject: [PATCH] configure.ac: call AC_USE_SYSTEM_EXTENSIONS
> +
> +With glibc 2.27 memfd_create() is inside a _GNU_SOURCE guard, so call
> +AC_USE_SYSTEM_EXTENSIONS to get this defined.
> +
> +Signed-off-by: Ross Burton <ross.burton@intel.com>
> +Signed-off-by: Romain Naour <romain.naour@gmail.com>

This looks liek it is a backport from upstream, right? If so, please say
so; in such a case I like to add something like:

    [yann: backport from upstream URL-or-commit]
    Signed-off-by: ME

Regards,
Yann E. MORIN.

> +---
> + configure.ac | 2 ++
> + 1 file changed, 2 insertions(+)
> +
> +diff --git a/configure.ac b/configure.ac
> +index 55772d0..ed77e6d 100644
> +--- a/configure.ac
> ++++ b/configure.ac
> +@@ -28,6 +28,8 @@ AC_INIT([libxshmfence], [1.2],
> + AC_CONFIG_SRCDIR([Makefile.am])
> + AC_CONFIG_HEADERS([config.h])
> + 
> ++AC_USE_SYSTEM_EXTENSIONS
> ++
> + # Initialize Automake
> + AM_INIT_AUTOMAKE([foreign dist-bzip2])
> + 
> +-- 
> +2.14.3
> +
> diff --git a/package/x11r7/xlib_libxshmfence/xlib_libxshmfence.mk b/package/x11r7/xlib_libxshmfence/xlib_libxshmfence.mk
> index 3a2f32623a..9686c408c1 100644
> --- a/package/x11r7/xlib_libxshmfence/xlib_libxshmfence.mk
> +++ b/package/x11r7/xlib_libxshmfence/xlib_libxshmfence.mk
> @@ -12,4 +12,7 @@ XLIB_LIBXSHMFENCE_LICENSE_FILES = COPYING
>  XLIB_LIBXSHMFENCE_INSTALL_STAGING = YES
>  XLIB_LIBXSHMFENCE_DEPENDENCIES = host-pkgconf xproto_xproto
>  
> +# 0001-configure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch
> +XLIB_LIBXSHMFENCE_AUTORECONF = YES
> +
>  $(eval $(autotools-package))
> -- 
> 2.14.3
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1/5] package/x11r7/xlib_libxshmfence: fix build with glibc 2.27

[Thomas Petazzoni]

Hello,

On Mon,  5 Feb 2018 21:57:12 +0100, Romain Naour wrote:
> With glibc 2.27 memfd_create() is inside a _GNU_SOURCE guard, so call
> AC_USE_SYSTEM_EXTENSIONS to get this defined.
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> ---
>  ...onfigure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch | 30 ++++++++++++++++++++++
>  .../x11r7/xlib_libxshmfence/xlib_libxshmfence.mk   |  3 +++
>  2 files changed, 33 insertions(+)
>  create mode 100644 package/x11r7/xlib_libxshmfence/0001-configure.ac-call-AC_USE_SYSTEM_EXTENSIONS.patch

Thanks, I've applied the series to the next branch.

For PATCH 1, I added a reference to the upstream commit you've
backported, as suggested by Yann.

For PATCH 5, I added the references to the CVEs being fixed, tweaked
the commit log about license file hashes, and changed the title to
"security bump".

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com