[Buildroot] [pull request] Pull request for branch misc-fixes

[Buildroot] [pull request] Pull request for branch misc-fixes

[Thomas Petazzoni]

The following changes since commit d701a82321ad2f3e5bfa16639e93532294cad4ce:
  Paulius Zaleckas (1):
        Remove gtk-doc documentations from target

are available in the git repository at:

  git://git.busybox.net/~tpetazzoni/git/buildroot misc-fixes

Thomas Petazzoni (3):
      busybox: disable MTD utils in default configuration
      libxcb: fix path to Python modules
      xlib_libX11: re-add a patch to fix the keysymdef issue

 package/busybox/busybox-1.16.x.config              |    8 ++--
 package/x11r7/libxcb/libxcb.mk                     |    3 +-
 .../xlib_libX11/xlib_libX11-1.3.2-keysymdef.patch  |   35 ++++++++++++++++++++
 3 files changed, 41 insertions(+), 5 deletions(-)
 create mode 100644 package/x11r7/xlib_libX11/xlib_libX11-1.3.2-keysymdef.patch

Thanks,
-- 
Thomas Petazzoni

[Buildroot] [PATCH 1/3] busybox: disable MTD utils in default configuration

[Thomas Petazzoni]

The MTD utils require MTD headers in the toolchain, and in several
external toolchains, they are not present. In order to make the build
work by default, let's disable the MTD Busybox applets in our default
configuration.

Fixes bug #1669

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/busybox/busybox-1.16.x.config |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/package/busybox/busybox-1.16.x.config b/package/busybox/busybox-1.16.x.config
index 0b3dcc5..e5f5102 100644
--- a/package/busybox/busybox-1.16.x.config
+++ b/package/busybox/busybox-1.16.x.config
@@ -604,10 +604,10 @@ CONFIG_DEVMEM=y
 CONFIG_EJECT=y
 # CONFIG_FEATURE_EJECT_SCSI is not set
 # CONFIG_FBSPLASH is not set
-CONFIG_FLASHCP=y
-CONFIG_FLASH_LOCK=y
-CONFIG_FLASH_UNLOCK=y
-CONFIG_FLASH_ERASEALL=y
+# CONFIG_FLASHCP is not set
+# CONFIG_FLASH_LOCK is not set
+# CONFIG_FLASH_UNLOCK is not set
+# CONFIG_FLASH_ERASEALL is not set
 # CONFIG_IONICE is not set
 # CONFIG_INOTIFYD is not set
 CONFIG_LAST=y
-- 
1.6.3.3

[Buildroot] [PATCH 2/3] libxcb: fix path to Python modules

[Thomas Petazzoni]

When building libxcb, the variable XCBPROTO_XCBPYTHONDIR must point to
the location where the Python modules needed to run the c_client.py
program are installed. The path
$(STAGING_DIR)/usr/lib/python2.6/site-packages was hardcoded. However,
it doesn't work when the version of Python installed on the host is
Python 2.5.

Therefore, add a little bit of magic to compute the host Python
version.

Fixes bug #1531.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/x11r7/libxcb/libxcb.mk |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/package/x11r7/libxcb/libxcb.mk b/package/x11r7/libxcb/libxcb.mk
index ec9843e..c8b70ea 100644
--- a/package/x11r7/libxcb/libxcb.mk
+++ b/package/x11r7/libxcb/libxcb.mk
@@ -13,7 +13,8 @@ LIBXCB_AUTORECONF = NO
 LIBXCB_LIBTOOL_PATCH = NO
 LIBXCB_DEPENDENCIES = host-libxslt pthread-stubs xcb-proto xlib_libXdmcp xlib_libXau
 LIBXCB_CONF_ENV = STAGING_DIR="$(STAGING_DIR)"
-LIBXCB_MAKE_OPT = XCBPROTO_XCBINCLUDEDIR=$(STAGING_DIR)/usr/share/xcb XCBPROTO_XCBPYTHONDIR=$(STAGING_DIR)/usr/lib/python2.6/site-packages
+HOST_PYTHON_VERSION=$(shell python --version 2>&1 | sed 's/Python \(2\.[0-9]\)\..*/\1/')
+LIBXCB_MAKE_OPT = XCBPROTO_XCBINCLUDEDIR=$(STAGING_DIR)/usr/share/xcb XCBPROTO_XCBPYTHONDIR=$(STAGING_DIR)/usr/lib/python$(HOST_PYTHON_VERSION)/site-packages
 
 $(eval $(call AUTOTARGETS,package/x11r7,libxcb))
 
-- 
1.6.3.3

[Buildroot] [PATCH 3/3] xlib_libX11: re-add a patch to fix the keysymdef issue

[Thomas Petazzoni]

When xlib_libX11 was bumped to 1.3.2 in commit
1d956c9190dafbe425e9e02255b540641e27f690, the keysymdef patch was
dropped. However, this patch is still needed in order to be able to
tell ./configure where the keysymdef header file is installed.

The patch has been updated for 1.3.2.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 .../xlib_libX11/xlib_libX11-1.3.2-keysymdef.patch  |   35 ++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)
 create mode 100644 package/x11r7/xlib_libX11/xlib_libX11-1.3.2-keysymdef.patch

diff --git a/package/x11r7/xlib_libX11/xlib_libX11-1.3.2-keysymdef.patch b/package/x11r7/xlib_libX11/xlib_libX11-1.3.2-keysymdef.patch
new file mode 100644
index 0000000..9c4eae2
--- /dev/null
+++ b/package/x11r7/xlib_libX11/xlib_libX11-1.3.2-keysymdef.patch
@@ -0,0 +1,35 @@
+[patch]: configure: add --with-keysymdef argument for cross compilation
+
+Based on a similar patch from Openembedded.
+
+The libX11 configure script hardcodes the location to keysymdef.h as
+<prefix>/include/X11/keysymdef.h, which is fine for native compilation,
+but breaks with cross compilation as that directory is a location on
+the target, not the build host.
+
+Fix it by providing an explicit --with-keysymdef=<full-path-to-file>.
+
+Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>Index: libX11-1.1.5/configure.ac
+===================================================================
+Index: xlib_libX11-1.3.2/configure.ac
+===================================================================
+--- xlib_libX11-1.3.2.orig/configure.ac	2009-10-23 22:55:03.000000000 +0200
++++ xlib_libX11-1.3.2/configure.ac	2010-05-04 16:26:39.000000000 +0200
+@@ -280,8 +280,15 @@
+ # Find keysymdef.h
+ #
+ AC_MSG_CHECKING([keysymdef.h])
+-dir=`pkg-config --variable=includedir xproto`
+-KEYSYMDEF="$dir/X11/keysymdef.h"
++AC_ARG_WITH(keysymdef,
++      AC_HELP_STRING([--with-keysymdef=DIR/keysymdef.h], [The location of keysymdef.h]),
++      KEYSYMDEF=$withval, KEYSYMDEF="")
++
++if test x$KEYSYMDEF = x; then
++      dir=`pkg-config --variable=includedir xproto`
++      KEYSYMDEF="$dir/X11/keysymdef.h"
++fi
++
+ if test -f "$KEYSYMDEF"; then
+         AC_MSG_RESULT([$KEYSYMDEF])
+ else
-- 
1.6.3.3

[Buildroot] [PATCH 2/3] libxcb: fix path to Python modules

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> When building libxcb, the variable XCBPROTO_XCBPYTHONDIR must point to
 Thomas> the location where the Python modules needed to run the c_client.py
 Thomas> program are installed. The path
 Thomas> $(STAGING_DIR)/usr/lib/python2.6/site-packages was hardcoded. However,
 Thomas> it doesn't work when the version of Python installed on the host is
 Thomas> Python 2.5.

So we depend on python being available on the host? Shouldn't we just
use the hostpython stuff we already have and E.G
$(PYTHON_VERSION_MAJOR)?

Alternatively we should probably add a check in libxcb.mk and print an
$(error if it isn't there.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2/3] libxcb: fix path to Python modules

[Thomas Petazzoni]

Hello,

On Thu, 06 May 2010 10:59:18 +0200
Peter Korsgaard <jacmet@uclibc.org> wrote:

> So we depend on python being available on the host?

Yes, we do.

> Shouldn't we just use the hostpython stuff we already have and E.G
> $(PYTHON_VERSION_MAJOR)?

Well, the hostpython stuff we already have only makes Python on the
host available to build Python on the target. It isn't a normal host
package in that it doesn't install anything in $(HOST_DIR). That could
be changed, of course.

So, you think we should consider not Python as being a mandatory system
dependency, just as Perl is already ?

I have no strong opinion on this, but Python is nowadays installed on
virtually every system, and rebuilding it from the host will probably
take quite some time.

> Alternatively we should probably add a check in libxcb.mk and print an
> $(error if it isn't there.

Yes, we could do that as well.

The other ugly thing is that we are running a Python program on the
host, while using modules installed in
$(STAGING_DIR)/usr/lib/pythonX.Y/site-packages.

BTW, I have another question regarding dependencies. For the moment,
the X.org font packages do not build on a host were some X.org
utilities are not available (mkfontdir, mkfontscale, pdftopcf and so
on). I've fixed some of them already, but I'm now facing the problem of
xapp_bdftopcf, which needs to be built for the host. Unfortunately,
this tool depends on xlib_libXfont for the host, which itself would
depend on freetype xlib_libfontenc xlib_xtrans xproto_fontcacheproto
xproto_fontsproto xproto_xproto xfont_encodings.

Do we build all these things for the host ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 2/3] libxcb: fix path to Python modules

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Hello,
 Thomas> On Thu, 06 May 2010 10:59:18 +0200
 Thomas> Peter Korsgaard <jacmet@uclibc.org> wrote:

 >> So we depend on python being available on the host?

 Thomas> Yes, we do.

 >> Shouldn't we just use the hostpython stuff we already have and E.G
 >> $(PYTHON_VERSION_MAJOR)?

 Thomas> Well, the hostpython stuff we already have only makes Python on the
 Thomas> host available to build Python on the target. It isn't a normal host
 Thomas> package in that it doesn't install anything in $(HOST_DIR). That could
 Thomas> be changed, of course.

Yes.

 Thomas> So, you think we should consider not Python as being a
 Thomas> mandatory system dependency, just as Perl is already ?

Not necessarily, but we should check for it (either in dependencies.sh
or in libxcb.mk if it is only needed there) so the user gets a sensible
error message if it isn't available.

 Thomas> I have no strong opinion on this, but Python is nowadays
 Thomas> installed on virtually every system, and rebuilding it from the
 Thomas> host will probably take quite some time.

Our Python stuff is quite weak, I could imagine that we might need a
specific version of host python to build other stuff in the future, but
that's not something we need to fix for 2010.05.

 >> Alternatively we should probably add a check in libxcb.mk and print an
 >> $(error if it isn't there.

 Thomas> Yes, we could do that as well.

 Thomas> The other ugly thing is that we are running a Python program on the
 Thomas> host, while using modules installed in
 Thomas> $(STAGING_DIR)/usr/lib/pythonX.Y/site-packages.

 Thomas> BTW, I have another question regarding dependencies. For the moment,
 Thomas> the X.org font packages do not build on a host were some X.org
 Thomas> utilities are not available (mkfontdir, mkfontscale, pdftopcf and so
 Thomas> on). I've fixed some of them already, but I'm now facing the problem of
 Thomas> xapp_bdftopcf, which needs to be built for the host. Unfortunately,
 Thomas> this tool depends on xlib_libXfont for the host, which itself would
 Thomas> depend on freetype xlib_libfontenc xlib_xtrans xproto_fontcacheproto
 Thomas> xproto_fontsproto xproto_xproto xfont_encodings.

 Thomas> Do we build all these things for the host ?

Argh. How many of these are we already building for a "normal" Xorg
build (E.G. probably most people use gtk as well) - freetype I guess
would be. The *proto packages are tiny, so they shouldn't be a
problem. That leaves the xlib_* stuff - Do you have any idea if they
take significant time to build?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2/3] libxcb: fix path to Python modules

[Thomas Petazzoni]

When building libxcb, the variable XCBPROTO_XCBPYTHONDIR must point to
the location where the Python modules needed to run the c_client.py
program are installed. The path
$(STAGING_DIR)/usr/lib/python2.6/site-packages was hardcoded. However,
it doesn't work when the version of Python installed on the host is
Python 2.5.

Therefore, add a little bit of magic to compute the host Python
version.

We also verify that Python is available on the host, as we don't build
it in Buildroot.

Fixes bug #1531.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/x11r7/libxcb/libxcb.mk         |    3 ++-
 toolchain/dependencies/dependencies.sh |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/package/x11r7/libxcb/libxcb.mk b/package/x11r7/libxcb/libxcb.mk
index ec9843e..c8b70ea 100644
--- a/package/x11r7/libxcb/libxcb.mk
+++ b/package/x11r7/libxcb/libxcb.mk
@@ -13,7 +13,8 @@ LIBXCB_AUTORECONF = NO
 LIBXCB_LIBTOOL_PATCH = NO
 LIBXCB_DEPENDENCIES = host-libxslt pthread-stubs xcb-proto xlib_libXdmcp xlib_libXau
 LIBXCB_CONF_ENV = STAGING_DIR="$(STAGING_DIR)"
-LIBXCB_MAKE_OPT = XCBPROTO_XCBINCLUDEDIR=$(STAGING_DIR)/usr/share/xcb XCBPROTO_XCBPYTHONDIR=$(STAGING_DIR)/usr/lib/python2.6/site-packages
+HOST_PYTHON_VERSION=$(shell python --version 2>&1 | sed 's/Python \(2\.[0-9]\)\..*/\1/')
+LIBXCB_MAKE_OPT = XCBPROTO_XCBINCLUDEDIR=$(STAGING_DIR)/usr/share/xcb XCBPROTO_XCBPYTHONDIR=$(STAGING_DIR)/usr/lib/python$(HOST_PYTHON_VERSION)/site-packages
 
 $(eval $(call AUTOTARGETS,package/x11r7,libxcb))
 
diff --git a/toolchain/dependencies/dependencies.sh b/toolchain/dependencies/dependencies.sh
index 013c1d5..923c76b 100755
--- a/toolchain/dependencies/dependencies.sh
+++ b/toolchain/dependencies/dependencies.sh
@@ -122,7 +122,7 @@ if ! $SHELL --version 2>&1 | grep -q '^GNU bash'; then
 fi;
 
 # Check that a few mandatory programs are installed
-for prog in awk bison flex msgfmt makeinfo patch gzip bzip2 perl tar wget cpio ; do
+for prog in awk bison flex msgfmt makeinfo patch gzip bzip2 perl tar wget cpio python ; do
     if ! which $prog > /dev/null ; then
 	/bin/echo -e "\nYou must install '$prog' on your build machine";
 	if test $prog = "makeinfo" ; then
-- 
1.6.3.3

[Buildroot] [pull request] Pull request for branch misc-fixes

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> The following changes since commit d701a82321ad2f3e5bfa16639e93532294cad4ce:
 Thomas>   Paulius Zaleckas (1):
 Thomas>         Remove gtk-doc documentations from target

 Thomas> are available in the git repository at:

 Thomas>   git://git.busybox.net/~tpetazzoni/git/buildroot misc-fixes

Pulled, thanks!

-- 
Bye, Peter Korsgaard