Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [Bug 5666] Fails to build python 2.7.2 for 2440 arm
From: bugzilla at busybox.net @ 2012-11-12 22:32 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <bug-5666-163@https.bugs.busybox.net/>

https://bugs.busybox.net/show_bug.cgi?id=5666

--- Comment #4 from hardcorefs <hardcore@hardcoreforensics.com> 2012-11-12 22:32:37 UTC ---
HI,
Yep you are indeed a fortune teller........
Did "make clean all" and it did solve the problem, just it extends the build
time every time.

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

^ permalink raw reply

* [Buildroot] [PATCH v2 6/6] Add config file for the snowball board
From: Arnout Vandecappelle @ 2012-11-12 21:53 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352742102-19010-7-git-send-email-gregory.hermant@calao-systems.com>

On 11/12/12 18:41, Gregory Hermant wrote:
>
> Signed-off-by: Gregory Hermant<gregory.hermant@calao-systems.com>
> ---
>   configs/calao_snowball_defconfig |   49 ++++++++++++++++++++++++++++++++++++++
>   1 file changed, 49 insertions(+)
>   create mode 100644 configs/calao_snowball_defconfig
>
> diff --git a/configs/calao_snowball_defconfig b/configs/calao_snowball_defconfig
> new file mode 100644
> index 0000000..e5e67bf
> --- /dev/null
> +++ b/configs/calao_snowball_defconfig
> @@ -0,0 +1,49 @@
> +BR2_arm=y
> +BR2_cortex_a9=y
> +BR2_GCC_VERSION_4_7_X=y
> +# BR2_SOFT_FLOAT is not set
> +BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y
> +BR2_TOOLCHAIN_BUILDROOT_INET_IPV6=y
> +BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
> +BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
> +BR2_TOOLCHAIN_BUILDROOT_CXX=y
> +BR2_VFP_FLOAT=y
> +BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV=y
> +BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA2"
> +BR2_PACKAGE_BUSYBOX_CONFIG="board/calao/snowball/busybox-1.20.x.config"
> +BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
> +BR2_PACKAGE_BZIP2=y
> +BR2_PACKAGE_FBSET=y
> +BR2_PACKAGE_FBTERM=y
> +BR2_PACKAGE_HDMISERVICE=y
> +BR2_PACKAGE_MINICOM=y
> +BR2_PACKAGE_LUA=y
> +BR2_PACKAGE_OPENSSL=y
> +BR2_PACKAGE_SQLITE=y
> +BR2_PACKAGE_JPEG=y
> +BR2_PACKAGE_LIBPNG=y
> +BR2_PACKAGE_LIBUNGIF=y
> +BR2_PACKAGE_LIBELF=y
> +BR2_PACKAGE_PCRE=y
> +BR2_PACKAGE_LIBXML2=y
> +BR2_PACKAGE_SNOWBALL_INIT=y
> +BR2_PACKAGE_IW=y
> +BR2_PACKAGE_WGET=y

  I have the feeling that I've said this before, but: are all of these
really needed?  I can't imagine why you'd want anything that is also
already provided by busybox; I don't see why you'd need minicom or lua
in a minimal configuration; all the libraries make no sense if there
no package using them, but then that package should select them.

  For the wireless packages below I'm willing to make an exception
(though I'm not sure why the lib is needed).

> +BR2_PACKAGE_WIRELESS_TOOLS=y
> +BR2_PACKAGE_WIRELESS_TOOLS_LIB=y
> +BR2_PACKAGE_WPA_SUPPLICANT=y
> +BR2_PACKAGE_WPA_SUPPLICANT_EAP=y
> +BR2_PACKAGE_WPA_SUPPLICANT_CLI=y
> +BR2_PACKAGE_WPA_SUPPLICANT_PASSPHRASE=y
> +BR2_PACKAGE_WPA_SUPPLICANT_AP_SUPPORT=y
> +BR2_PACKAGE_WPA_SUPPLICANT_WPS=y
> +BR2_TARGET_ROOTFS_TAR_GZIP=y

  I thought the idea was to put it on an SD card?  Then it makes more
sense to build an ext2 fs, no?


  Regards,
  Arnout

> +BR2_TARGET_UBOOT=y
> +BR2_TARGET_UBOOT_BOARDNAME="snowball"
> +BR2_LINUX_KERNEL=y
> +BR2_LINUX_KERNEL_CUSTOM_GIT=y
> +BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://igloocommunity.org/git/kernel/igloo-kernel.git"
> +BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="stable-linux-ux500-3.4"
> +BR2_LINUX_KERNEL_PATCH="board/calao/snowball/"
> +BR2_LINUX_KERNEL_DEFCONFIG="u8500"
> +BR2_LINUX_KERNEL_INSTALL_TARGET=y

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply

* [Buildroot] [PATCH v2 5/6] bluez-utils: add cg2900 support for snowball board
From: Arnout Vandecappelle @ 2012-11-12 21:47 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352742102-19010-6-git-send-email-gregory.hermant@calao-systems.com>

On 11/12/12 18:41, Gregory Hermant wrote:
>
> Signed-off-by: Gregory Hermant<gregory.hermant@calao-systems.com>
> ---
>   ...an_patches_enable_cg2900_on_upstream_4.91.patch |   88 ++++++++++++++++++++
>   1 file changed, 88 insertions(+)
>   create mode 100644 package/bluez_utils/bluez_utils-4.101-debian_patches_enable_cg2900_on_upstream_4.91.patch
>
> diff --git a/package/bluez_utils/bluez_utils-4.101-debian_patches_enable_cg2900_on_upstream_4.91.patch b/package/bluez_utils/bluez_utils-4.101-debian_patches_enable_cg2900_on_upstream_4.91.patch
> new file mode 100644
> index 0000000..02b84c4
> --- /dev/null
> +++ b/package/bluez_utils/bluez_utils-4.101-debian_patches_enable_cg2900_on_upstream_4.91.patch
> @@ -0,0 +1,88 @@

  The patch file should have a description that explains why the patch is needed,
and where you got it from (i.e. similar to a commit message).  It should also
have your Signed-off-by.

[snip]

  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply

* [Buildroot] [PATCH v2 4/6] Add init script files for snowball board
From: Arnout Vandecappelle @ 2012-11-12 21:45 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352742102-19010-5-git-send-email-gregory.hermant@calao-systems.com>

On 11/12/12 18:41, Gregory Hermant wrote:
> Signed-off-by: Gregory Hermant<gregory.hermant@calao-systems.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
  (untested)

  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply

* [Buildroot] [PATCH v2 2/6] ux500-firmware: new package
From: Arnout Vandecappelle @ 2012-11-12 21:44 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352742102-19010-3-git-send-email-gregory.hermant@calao-systems.com>

On 11/12/12 18:41, Gregory Hermant wrote:
>
> Signed-off-by: Gregory Hermant<gregory.hermant@calao-systems.com>
> ---
>   package/Config.in                        |    1 +
>   package/ux500-firmware/Config.in         |    7 +++++++
>   package/ux500-firmware/ux500-firmware.mk |   20 ++++++++++++++++++++
>   3 files changed, 28 insertions(+)
>   create mode 100644 package/ux500-firmware/Config.in
>   create mode 100644 package/ux500-firmware/ux500-firmware.mk
>
> diff --git a/package/Config.in b/package/Config.in
> index cb78d2f..6da6e73 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -261,6 +261,7 @@ source "package/usb_modeswitch/Config.in"
>   source "package/usb_modeswitch_data/Config.in"
>   source "package/usbmount/Config.in"
>   source "package/usbutils/Config.in"
> +source "package/ux500-firmware/Config.in"
>   source "package/wipe/Config.in"
>   endmenu
>
> diff --git a/package/ux500-firmware/Config.in b/package/ux500-firmware/Config.in
> new file mode 100644
> index 0000000..7e8a94b
> --- /dev/null
> +++ b/package/ux500-firmware/Config.in
> @@ -0,0 +1,7 @@
> +config BR2_PACKAGE_UX500_FIRMWARE
> +	bool "ux500-firmware"
> +	help
> +	  This package provides various binary firmware files (closed binary blobs)
> +	  for the Azurewave AW-NH580 combo module (wifi, bt, gps).
> +
> +	  https://launchpad.net/~igloocommunity-maintainers/+archive/snowball/+files/
> diff --git a/package/ux500-firmware/ux500-firmware.mk b/package/ux500-firmware/ux500-firmware.mk
> new file mode 100644
> index 0000000..522113a
> --- /dev/null
> +++ b/package/ux500-firmware/ux500-firmware.mk
> @@ -0,0 +1,20 @@
> +#############################################################
> +#
> +# ux500-firmware
> +#
> +#############################################################
> +UX500_FIRMWARE_VERSION = 1.1.3-6
> +UX500_FIRMWARE_SOURCE = ux500-firmware_$(UX500_FIRMWARE_VERSION)linaro1.tar.gz
> +UX500_FIRMWARE_SITE = https://launchpad.net/~igloocommunity-maintainers/+archive/snowball/+files/
> +UX500_FIRMWARE_LICENSE = Snowball click-wrap license

  UX500_FIRMWARE_LICENSE_FILES = license.txt
> +UX500_FIRMWARE_REDISTRIBUTE = NO
> +
> +define UX500_FIRMWARE_INSTALL_TARGET_CMDS
> +	mkdir -p $(TARGET_DIR)/lib/firmware
> +	cp -r $(@D)/* $(TARGET_DIR)/lib/firmware/

  This also installs the debian directory etc. to the target.  Why not use
the Makefile that is delivered with the package?

> +	for f in $(TARGET_DIR)/lib/firmware/CG2900* ; do \
> +		mv $$f $${f/CG2900/CG29XX}; \
> +	done

  This warrants a comment why it is needed to rename some files.

> +endef
> +
> +$(eval $(generic-package))


  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply

* [Buildroot] [PATCH 2/2 v3] xtensa: support configurable processor configurations
From: Arnout Vandecappelle @ 2012-11-12 21:33 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <50A169FC.6010708@zankel.net>

On 11/12/12 22:28, Chris Zankel wrote:
> Hi Arnout,
>
> On 11/09/2012 04:51 PM, Arnout Vandecappelle wrote:
>> On 11/10/12 01:20, Chris Zankel wrote:
>>> +config BR2_xtensa_custom
>>> +	bool "Custom Xtensa processor configuration"
>>> +config BR2_xtensa_fsf
>>> +	bool "fsf - Default configuration"
>>> +endchoice
>>    Put empty lines between the different config options.
> Done.
>>    All config names should be in capitals - the only exception is the
>> arch name itself (i.e. BR2_xtensa, but BR2_XTENSA_FSF).
> To give you some background, 'fsf' describes the default configuration
> used in the various toolchain packages (gcc, buildroot, etc.). The idea
> is to append the name of the processor configuration (for example,
> dc232b), so to follow other architectures, I think it would be best to
> keep lower-case for processor names, and upper case for other options.
>
> For the case above, it would look like this:
>
> config BR_XTENSA_CUSTOM
> ...
>
> config BR_xtensa_fsf
> ...
>
> config BR_xtensa_dc232b
> ...
>
> etc.
>
> I actually think that this makes a nice distinction between processor
> names and buildroot configuration options.

  ACK good point.

>
>
>>> +
>>> +config BR2_xtensa_custom_name
>>> +	string "Custom Xtensa processor configuration anme"
>>    anme ->  name
> Done
>>
>>> +	depends on BR2_xtensa_custom
>>> +	default ""
>>> +	help
>>> +	  Name given to a custom Xtensa processor configuration.
>>> +
>>> +config BR2_xtensa_core_name
>>> +	string
>>> +	default BR2_xtensa_custom_name	if BR2_xtensa_custom
>>> +	default ""			if BR2_xtensa_fsf
>>    Minor detail: missing "depends on BR2_xtensa".
> Done.
>>    Perhaps it's better to move the condition to a
>> if BR2_xtensa
>> ...
>> endif
>> around the entire file.  Thomas has a patch lined up to move all
>> the conditions outside of the Config.in.*
> It seems Xtensa would be the only one that uses that scheme, so maybe
> wait for the generic patch from Thomas?

  I don't think so. Then it means more work for Thomas to refresh his
patch.  There will be a merge conflict anyway between the two, but
with the condition outside the file the conflict will be small.

  That said, Peter hasn't merged Thomas's patch even though I acked
it, so maybe he has some fundamental objection to the principle.
Or maybe it's just because I didn't test it.

  Bottom line: this issue won't stop my ack.

[snip]

  Regards,
  Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply

* [Buildroot] [PATCH 2/2 v3] xtensa: support configurable processor configurations
From: Chris Zankel @ 2012-11-12 21:28 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <509DA516.40007@mind.be>

Hi Arnout,

On 11/09/2012 04:51 PM, Arnout Vandecappelle wrote:
> On 11/10/12 01:20, Chris Zankel wrote:
>> +config BR2_xtensa_custom
>> +	bool "Custom Xtensa processor configuration"
>> +config BR2_xtensa_fsf
>> +	bool "fsf - Default configuration"
>> +endchoice
>   Put empty lines between the different config options.
Done.
>   All config names should be in capitals - the only exception is the
> arch name itself (i.e. BR2_xtensa, but BR2_XTENSA_FSF).
To give you some background, 'fsf' describes the default configuration
used in the various toolchain packages (gcc, buildroot, etc.). The idea
is to append the name of the processor configuration (for example,
dc232b), so to follow other architectures, I think it would be best to
keep lower-case for processor names, and upper case for other options.

For the case above, it would look like this:

config BR_XTENSA_CUSTOM
...

config BR_xtensa_fsf
...

config BR_xtensa_dc232b
...

etc.

I actually think that this makes a nice distinction between processor
names and buildroot configuration options.


>> +
>> +config BR2_xtensa_custom_name
>> +	string "Custom Xtensa processor configuration anme"
>   anme -> name
Done
>
>> +	depends on BR2_xtensa_custom
>> +	default ""
>> +	help
>> +	  Name given to a custom Xtensa processor configuration.
>> +
>> +config BR2_xtensa_core_name
>> +	string
>> +	default BR2_xtensa_custom_name	if BR2_xtensa_custom
>> +	default ""			if BR2_xtensa_fsf
>   Minor detail: missing "depends on BR2_xtensa".
Done.
>   Perhaps it's better to move the condition to a
> if BR2_xtensa
> ...
> endif
> around the entire file.  Thomas has a patch lined up to move all
> the conditions outside of the Config.in.*
It seems Xtensa would be the only one that uses that scheme, so maybe
wait for the generic patch from Thomas?

>> +
>> +config BR2_xtensa_overlay_dir
>> +	string "Overlay directory for custom configuration"
>> +	depends on BR2_xtensa_custom
>> +	default ""
>> +	help
>> +	  Provide a directory path that contains the overlay files
>> +	  for the custom configuration. The path is based on the
>> +	  buildroot top directory.
>   based on -> relative to
>
>   I don't find this explanation sufficient. First of all, it should
> mention that that directory should contain tar files. Second, it
> would help if you could explain where the tar files are supposed
> to come from (I guess they're generated by some Xtensa tool).
Made some additions, and will send a new set of patches in a bit...

-Chris
 

^ permalink raw reply

* [Buildroot] [PATCH for-2012.11 1/5] pkg-infra: introduce errors for legacy API
From: Arnout Vandecappelle @ 2012-11-12 21:18 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20121112220539.7e41409b@skate>

On 11/12/12 22:05, Thomas Petazzoni wrote:
>
> On Mon, 12 Nov 2012 21:08:28 +0100, Arnout Vandecappelle
>
>> +# Include legacy before the other things, because package .mk files
>> +# may rely on it.
>> +ifneq ($(BR2_DEPRECATED),y)
>> +include Makefile.legacy
>> +endif
>
> BR2_LEGACY here maybe?

  No that would not make sense - we want to get the error message if BR2_LEGACY
is selected (automatically, by Config.in.legacy).

The idea of the condition is to have an escape path, if you don't want to deal
with all the stuff that is misconfigured (not only legacy config symbols but also
host-pkg-config etc.), you can just build with BR2_DEPRECATED=y and see how far
you get.


  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply

* [Buildroot] QT packackage grantlee not building
From: Zoltan Gyarmati @ 2012-11-12 21:17 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <5ECF3E39D913490AB1D4F8AF7FA3450B@JohanW7>

On 11/11/2012 11:26 PM, Sagaert Johan wrote:
> Hi
>
>   I included my config
>
> Regards , Johan
>
>
>
> -----Oorspronkelijk bericht-----
> Van: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Namens Zoltan Gyarmati
> Verzonden: zondag 11 november 2012 22:05
> Aan: buildroot at busybox.net
> Onderwerp: Re: [Buildroot] QT packackage grantlee not building
>
> Hi,
>
> going to check it as soon a spossible, a defconfig would be useful indeed.
> Thx for the report!
>
> BR,
> Zoltan Gyarmati
>
>
>
> On 11/09/2012 10:48 PM, Arnout Vandecappelle wrote:
>> On 11/09/12 22:44, Sagaert Johan wrote:
>>> Currently the build of the QT grantlee package is broken:
>>> it seems like libpthread is not linked in.
>>   Could you post a defconfig so we can try to reproduce?
>>
>>   Regards,
>>   Arnout
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot


Hi,

i just managed to reproduce the issue, i'll send a patch to fix it, thx

-- 
br,
Zoltan Gyarmati
mail: mr.zoltan.gyarmati at gmail.com
freenode nick: zgyarmati

^ permalink raw reply

* [Buildroot] mesa3d:  "ImportError: No module named libxml2"
From: Arnout Vandecappelle @ 2012-11-12 21:06 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <50A0E402.1050805@carallon.com>

On 11/12/12 12:56, Will Wagner wrote:
> I ported newer X11 to buildroot a while back a posted a link to the repository. At the time the only comment I got was
> from Thomas about the requirement for python/libxml2 which he hated then as well :)
>
> I patched it so that it conditionally build host-libxml2 with the reuqired support if mesa3d was selected. My patch for
> this is at https://gitorious.org/willw-buildroot/willw-buildroot/commit/421b4fd572869b22de11a0f0fad161e284c41bcc
>
> If we want newer mesa3d support I think we are going to have to come up with some suitable solution for this.

  Yes, and your patch looks in pretty good shape already.  I would make
BR2_PACKAGE_HOST_LIBXML2_PYTHON a blind option (i.e. remove the string after
bool).  I'd also remove the dependency on BR2_PACKAGE_LIBXML2 (in fact,
mesa3d doesn't require libxml2).  And I'd keep the --without-debug.  But
otherwise the patch looks good :-)

  Care to post it to the list, followed by a mesa3d patch that uses it?

  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply

* [Buildroot] [PATCH for-2012.11 1/5] pkg-infra: introduce errors for legacy API
From: Thomas Petazzoni @ 2012-11-12 21:05 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352750912-16012-2-git-send-email-arnout@mind.be>


On Mon, 12 Nov 2012 21:08:28 +0100, Arnout Vandecappelle

> +# Include legacy before the other things, because package .mk files
> +# may rely on it.
> +ifneq ($(BR2_DEPRECATED),y)
> +include Makefile.legacy
> +endif

BR2_LEGACY here maybe?

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

^ permalink raw reply

* [Buildroot] [PATCH 0/2] add support for xtensa back to buildroot
From: Thomas Petazzoni @ 2012-11-12 21:01 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <50A15AAB.5020202@zankel.net>

Chris,

On Mon, 12 Nov 2012 12:23:07 -0800, Chris Zankel wrote:

> > Do you have any plans for proposing the support of a Qemu board using
> > the Xtensa architecture? Qemu already supports 2-3 platforms, so it
> > would be nice if Buildroot had a defconfig to generate a working system
> > for one of them.
> Yes, I'm planing to add support for QEMU, but it will probably take a
> bit to understand it better before I have a config and maybe some patches.

Excellent, thanks!

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

^ permalink raw reply

* [Buildroot] [PATCH] libtool version update 2.4.2
From: Arnout Vandecappelle @ 2012-11-12 20:57 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20121112112637.42d1a425@skate>

On 11/12/12 11:26, Thomas Petazzoni wrote:
> Stephan,
>
> On Mon, 12 Nov 2012 08:46:26 +0100, Stephan Hoffmann wrote:
>
>> did you ever think about inventing a kind of "testing" branch with a
>> seperate autobuilder running on? That could keep major build problems
>> away from the master branch.
>
> Yes, this has been discussed during the Developers Meeting, at least
> for the "next" branch that gets created once -rc1 is out, to accumulate
> patches for the next release.

  Actually it does make sense to have it in general.  We could allow more committers
on that branch, and Peter could cherry-pick from it, which could save him a few
seconds per patch.  And it could make master slightly more stable, because only
patches that don't kill the autobuilders would get cherry-picked.

  Maybe something to discuss in February.

  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply

* [Buildroot] [PATCH 0/2] add support for xtensa back to buildroot
From: Chris Zankel @ 2012-11-12 20:23 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20121110115729.357ebfdd@skate>

On 11/10/2012 02:57 AM, Thomas Petazzoni wrote:
>> I've also seen that Qemu has an Xtensa support. It would be nice if you
>> could create a qemu_xtensa_<somemachine>_defconfig with the necessary
>> kernel configuration and al (see other qemu_<foo>_defconfig that we
>> have in configs/) so that other people could build a Xtensa userspace
>> and run it inside qemu. At the moment, the qemu-system-xtensa supports
>> the following machines:
>>
>> $ qemu-system-xtensa -M ?
>> Supported machines are:
>> none                 empty machine
>> lx60                 lx60 EVB (dc232b)
>> lx200                lx200 EVB (dc232b)
>> sim                  sim machine (dc232b) (default)
> Do you have any plans for proposing the support of a Qemu board using
> the Xtensa architecture? Qemu already supports 2-3 platforms, so it
> would be nice if Buildroot had a defconfig to generate a working system
> for one of them.
Yes, I'm planing to add support for QEMU, but it will probably take a
bit to understand it better before I have a config and maybe some patches.

Thanks,
-Chris

^ permalink raw reply

* [Buildroot] [PATCH for-2012.11 5/5] legacy: BR2_PACKAGE_LIBINTL is replaced by gettext
From: Arnout Vandecappelle @ 2012-11-12 20:08 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352750912-16012-1-git-send-email-arnout@mind.be>

From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 Config.in.legacy |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/Config.in.legacy b/Config.in.legacy
index 04ccb92..7ddc6ea 100644
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -48,6 +48,21 @@ if BR2_LEGACY_CHECK_2012_11
 # Legacy options from 2012.08
 #
 
+config BR2_PACKAGE_GETTEXT_STATIC
+	bool "libgettext.a is now selected by BR2_PREFER_STATIC_LIB"
+	select BR2_LEGACY
+	help
+	  To build a static gettext library, select BR2_PREFER_STATIC_LIB.
+
+
+config BR2_PACKAGE_LIBINTL
+	bool "libintl"
+	select BR2_LEGACY
+	select BR2_PACKAGE_GETTEXT
+	help
+	  libintl is now installed by selecting BR2_PACKAGE_GETTEXT. This now
+	  only installs the library, not the executables.
+
 config BR2_PACKAGE_INPUT_TOOLS_EVTEST
 	bool "input-tools evtest is now a separate package evtest"
 	select BR2_LEGACY
-- 
1.7.10.4

^ permalink raw reply related

* [Buildroot] [PATCH for-2012.11 4/5] legacy: evtest is dropped from input-tools package
From: Arnout Vandecappelle @ 2012-11-12 20:08 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352750912-16012-1-git-send-email-arnout@mind.be>

From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>

We select BR2_PACKAGE_EVTEST automatically. This has only limited use:
when the LEGACY_CHECK menu is disabled in menuconfig (or even oldconfig),
it will also unselect BR2_PACKAGE_EVTEST again. Still, it can serve as a
hint of how to fix things.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 Config.in.legacy |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Config.in.legacy b/Config.in.legacy
index 4bc8784..04ccb92 100644
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -48,4 +48,11 @@ if BR2_LEGACY_CHECK_2012_11
 # Legacy options from 2012.08
 #
 
+config BR2_PACKAGE_INPUT_TOOLS_EVTEST
+	bool "input-tools evtest is now a separate package evtest"
+	select BR2_LEGACY
+	select BR2_PACKAGE_EVTEST
+	help
+	  The evtest program from input-tools is now a separate package.
+
 endif
-- 
1.7.10.4

^ permalink raw reply related

* [Buildroot] [PATCH for-2012.11 3/5] legacy: add error target for host-pkg-config
From: Arnout Vandecappelle @ 2012-11-12 20:08 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352750912-16012-1-git-send-email-arnout@mind.be>

From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 Makefile.legacy |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Makefile.legacy b/Makefile.legacy
index c8b568d..e0b7ec2 100644
--- a/Makefile.legacy
+++ b/Makefile.legacy
@@ -13,6 +13,16 @@ $(error "You have legacy configuration in your .config! Please check your config
 endif
 
 #
+# Legacy options from 2012.08
+#
+
+host-pkg-config:
+	@$(call MESSAGE,host-pkg-config is replaced by host-pkgconf)
+	@$(call MESSAGE,please update your .mk files)
+	@false
+.PHONY: host-pkg-config
+
+#
 # Legacy options from 2012.05
 #
 GENTARGETS = $$(error The GENTARGETS macro no longer exists; use $$$$(eval $$$$(generic-package)) or $$$$(eval $$$$(host-generic-package)))
-- 
1.7.10.4

^ permalink raw reply related

* [Buildroot] [PATCH for-2012.11 2/5] legacy: move old GENTARGETS macros to Makefile.legacy
From: Arnout Vandecappelle @ 2012-11-12 20:08 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352750912-16012-1-git-send-email-arnout@mind.be>

From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 Makefile.legacy     |    7 +++++++
 package/Makefile.in |    6 ------
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Makefile.legacy b/Makefile.legacy
index 2e015a1..c8b568d 100644
--- a/Makefile.legacy
+++ b/Makefile.legacy
@@ -11,3 +11,10 @@
 ifeq ($(BR2_LEGACY),y)
 $(error "You have legacy configuration in your .config! Please check your configuration.")
 endif
+
+#
+# Legacy options from 2012.05
+#
+GENTARGETS = $$(error The GENTARGETS macro no longer exists; use $$$$(eval $$$$(generic-package)) or $$$$(eval $$$$(host-generic-package)))
+AUTOTARGETS = $$(error The AUTOTARGETS macro no longer exists; use $$$$(eval $$$$(autotools-package)) or $$$$(eval $$$$(host-autotools-package)))
+CMAKETARGETS = $$(error The CMAKETARGETS macro no longer exists; use $$$$(eval $$$$(cmake-package)) or $$$$(eval $$$$(host-cmake-package)))
diff --git a/package/Makefile.in b/package/Makefile.in
index 9fdc745..2dd81c7 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -305,12 +305,6 @@ else
 SHARED_STATIC_LIBS_OPTS=--enable-static --enable-shared
 endif
 
-# Warn if a package uses the deprecated GENTARGETS macros.  This can be
-# removed again for BR-2012.11.
-GENTARGETS = $$(error The GENTARGETS macro no longer exists; use $$$$(eval $$$$(generic-package)) or $$$$(eval $$$$(host-generic-package)))
-AUTOTARGETS = $$(error The AUTOTARGETS macro no longer exists; use $$$$(eval $$$$(autotools-package)) or $$$$(eval $$$$(host-autotools-package)))
-CMAKETARGETS = $$(error The CMAKETARGETS macro no longer exists; use $$$$(eval $$$$(cmake-package)) or $$$$(eval $$$$(host-cmake-package)))
-
 include package/pkg-utils.mk
 include package/pkg-download.mk
 include package/pkg-autotools.mk
-- 
1.7.10.4

^ permalink raw reply related

* [Buildroot] [PATCH for-2012.11 1/5] pkg-infra: introduce errors for legacy API
From: Arnout Vandecappelle @ 2012-11-12 20:08 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352750912-16012-1-git-send-email-arnout@mind.be>

From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>

As discussed in the BR developer days, we want to be more strict about API
changes in buildroot. I.e., we want to make it less likely that a user's
customizations break down after upgrading buildroot.

A first step is to make sure that the user is warned about API changes.
This patch introduces Makefile.legacy and Config.in.legacy, which will
issue clear error messages for such situations.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 Config.in        |    2 ++
 Config.in.legacy |   51 +++++++++++++++++++++++++++++++++++++++++++++++++++
 Makefile         |    7 ++++++-
 Makefile.legacy  |   13 +++++++++++++
 4 files changed, 72 insertions(+), 1 deletion(-)
 create mode 100644 Config.in.legacy
 create mode 100644 Makefile.legacy

diff --git a/Config.in b/Config.in
index 68190a5..71b811b 100644
--- a/Config.in
+++ b/Config.in
@@ -430,3 +430,5 @@ source "fs/Config.in"
 source "boot/Config.in"
 
 source "linux/Config.in"
+
+source "Config.in.legacy"
diff --git a/Config.in.legacy b/Config.in.legacy
new file mode 100644
index 0000000..4bc8784
--- /dev/null
+++ b/Config.in.legacy
@@ -0,0 +1,51 @@
+#
+# Config.in.legacy - support for backward compatibility
+#
+# When an existing Config.in symbol is removed, it should be added again in this
+# file, and take appropriate action to approximate backward compatibility. If
+# there is an equivalent (set of) new symbols, these can just be select'ed by
+# the old symbol. This makes sure that running 'make oldconfig' will make things
+# "just work" when upgrading to a new buildroot version. If the change is too
+# fundamental and cannot be fixed by a simple select, then the old symbol should
+# select BR2_LEGACY.  If that symbol is set, the build will issue an error.
+#
+# When adding legacy symbols to this file, add them to the front. The oldest
+# symbols will be removed again after about two years.
+#
+# The symbol should be copied as-is from the place where it was previously
+# defined, but the help text should be removed or replaced with something that
+# explains how to fix it.
+
+config BR2_LEGACY
+	bool
+	help
+	  This option is selected automatically when your old .config uses an
+	  option that no longer exists in current buildroot. In that case, the
+	  build will fail. Look for config options which are selected in the
+	  menu below: they no longer exist and should be replaced by something
+	  else.
+
+# This comment fits exactly in a 80-column display
+comment "Legacy detected: check the content of the menu below"
+	depends on BR2_LEGACY
+
+# This option should get a new name with every buildroot release, so it defaults
+# to y again for people who upgrade.
+menuconfig BR2_LEGACY_CHECK_2012_11
+	bool "Check for legacy config options"
+	default y
+	help
+	  Select this option to see the config options that are present in your
+	  current .config but are no longer supported by buildroot. If any of
+	  the options in this menu is selected, they should be replaced with
+	  something else. As long as they stay selected, the build will fail.
+	  Just de-select this option to automatically remove all the legacy
+	  configuration.
+
+if BR2_LEGACY_CHECK_2012_11
+
+#
+# Legacy options from 2012.08
+#
+
+endif
diff --git a/Makefile b/Makefile
index c526fe1..300a0eb 100644
--- a/Makefile
+++ b/Makefile
@@ -286,6 +286,12 @@ endif
 
 all: world
 
+# Include legacy before the other things, because package .mk files
+# may rely on it.
+ifneq ($(BR2_DEPRECATED),y)
+include Makefile.legacy
+endif
+
 include package/Makefile.in
 include support/dependencies/dependencies.mk
 
@@ -756,4 +762,3 @@ print-version:
 include docs/manual/manual.mk
 
 .PHONY: $(noconfig_targets)
-
diff --git a/Makefile.legacy b/Makefile.legacy
new file mode 100644
index 0000000..2e015a1
--- /dev/null
+++ b/Makefile.legacy
@@ -0,0 +1,13 @@
+#
+# Makefile.legacy - support for backward compatibility
+#
+# This file contains placeholders to detect backward-compatibility problems.
+# When a buildroot "API" feature is being deprecated, a rule should be added
+# here that issues an error when the old feature is used.
+#
+# This file is not included if BR2_DEPRECATED is selected, so it is possible
+# to bypass the errors (although that's usually a bad idea).
+
+ifeq ($(BR2_LEGACY),y)
+$(error "You have legacy configuration in your .config! Please check your configuration.")
+endif
-- 
1.7.10.4

^ permalink raw reply related

* [Buildroot] [PATCH for-2012.11 0/5] Introduce errors for legacy API
From: Arnout Vandecappelle @ 2012-11-12 20:08 UTC (permalink / raw)
  To: buildroot

 This patch series introduces a mechanism to give relatively clear error
messages when legacy API is used. The first patch introduces the mechanism,
subsequent messages use it to report each of the API changes since 2012.08.

 Config options that are no longer supported are moved to Config.in.legacy.
When any of these is selected in an old .config file, a comment will appear
to warn the user of it, and it is possible to see which option caused the
error in the new 'Check legacy' menu.  Unselecting that menuconfig disables
all the legacy options in one go.

 If any such option remains, 'make' will fail immediately with a message
that legacy options are still selected.  However, if BR2_DEPRECATED is
selected, that error message is suppressed.

 To see this in action, do 'echo BR2_PACKAGE_LIBINTL >> .config' and run
make menuconfig; make.

 A new Makefile.in.legacy makes it possible to add make infrastructure
that warns about features that no longer exist.  Two examples are the
GENTARGETS macro (moved from package/Makefile.in) and the host-pkg-config
target.

 I've tried to find all the API changes since 2012.08, by looking at the
diffstat.  I probably didn't find them all, but it's better than nothing.

 There are two changes for which I don't have a solution.

- BR2_INET_RPC: since packages 'depend on' this option, there is really
no way to detect that some Config.in is still using it.  The result will
be that some packages are just not selectable. Hopefully that's enough
of a hint for users to find the issue.

- xtensa: since there are patches on the list to re-introduce xtensa,
I haven't added it to Config.in.legacy. If these xtensa patches don't
make it into 2012.11, then there probably should be a Config.in.legacy
for it.

 Regards,
 Arnout

^ permalink raw reply

* [Buildroot] [Bug 5222] pango1.14.x build failed for ARM
From: bugzilla at busybox.net @ 2012-11-12 19:37 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <bug-5222-163@https.bugs.busybox.net/>

https://bugs.busybox.net/show_bug.cgi?id=5222

--- Comment #6 from aleek <aleksander@dutkowski.me> 2012-11-12 19:37:10 UTC ---
Created attachment 4628
  --> https://bugs.busybox.net/attachment.cgi?id=4628
buildroot 2012.08 config file

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

^ permalink raw reply

* [Buildroot] [Bug 5222] pango1.14.x build failed for ARM
From: bugzilla at busybox.net @ 2012-11-12 19:35 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <bug-5222-163@https.bugs.busybox.net/>

https://bugs.busybox.net/show_bug.cgi?id=5222

--- Comment #5 from aleek <aleksander@dutkowski.me> 2012-11-12 19:35:55 UTC ---
(In reply to comment #4)
> Are you still seeing these problems?
I have same problem with buildroot 2012.08 and pango 1.28.4

>>> pango 1.28.4 Building
PATH="/usr/aleek/arm/buildroot-2012.08/output/host/bin:/usr/aleek/arm/buildroot-2012.08/output/host/usr/bin:/usr/aleek/arm/buildroot-2012.08/output/host/usr/sbin/:/home/alek/bin/i686-nptl-linux-gnu/bin:/home/alek/bin/arm-2011.09/bin:/home/alek/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
PERLLIB="/usr/aleek/arm/buildroot-2012.08/output/host/usr/lib/perl" 
/usr/bin/make -j8  -C
/usr/aleek/arm/buildroot-2012.08/output/build/pango-1.28.4/
make[1]: Entering directory
`/usr/aleek/arm/buildroot-2012.08/output/build/pango-1.28.4'
/usr/bin/make  all-recursive
make[2]: Entering directory
`/usr/aleek/arm/buildroot-2012.08/output/build/pango-1.28.4'
Making all in pango
make[3]: Entering directory
`/usr/aleek/arm/buildroot-2012.08/output/build/pango-1.28.4/pango'
  GEN    s-enum-types-h
  GEN    s-enum-types-c
/usr/bin/make  all-recursive
make[4]: Entering directory
`/usr/aleek/arm/buildroot-2012.08/output/build/pango-1.28.4/pango'
Making all in opentype
make[5]: Entering directory
`/usr/aleek/arm/buildroot-2012.08/output/build/pango-1.28.4/pango/opentype'
  CC     libharfbuzz_la-hb-blob.lo
  CC     libharfbuzz_la-hb-buffer.lo
  CXX    libharfbuzz_la-hb-font.lo
  CC     libharfbuzz_la-hb-glib.lo
  CC     libharfbuzz_la-hb-shape.lo
  CC     libharfbuzz_la-hb-unicode.lo
  CXX    libharfbuzz_la-hb-ot-layout.lo
  CXX    main-main.o
  CXXLD  libharfbuzz.la
libtool: link: warning: library
`/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/lib/libgobject-2.0.la'
was moved.
/bin/grep:
/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/build/libglib2-2.30.2/gthread/libgthread-2.0.la:
No such file or directory
/bin/sed: can't read
/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/build/libglib2-2.30.2/gthread/libgthread-2.0.la:
No such file or directory
libtool: link:
`/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/aleek/arm/buildroot-2012.08/output/build/libglib2-2.30.2/gthread/libgthread-2.0.la'
is not a valid libtool archive
make[5]: *** [libharfbuzz.la] Error 1
make[5]: Leaving directory
`/usr/aleek/arm/buildroot-2012.08/output/build/pango-1.28.4/pango/opentype'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/usr/aleek/arm/buildroot-2012.08/output/build/pango-1.28.4/pango'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/usr/aleek/arm/buildroot-2012.08/output/build/pango-1.28.4/pango'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/usr/aleek/arm/buildroot-2012.08/output/build/pango-1.28.4'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/usr/aleek/arm/buildroot-2012.08/output/build/pango-1.28.4'
make: ***
[/usr/aleek/arm/buildroot-2012.08/output/build/pango-1.28.4/.stamp_built] Error
2

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

^ permalink raw reply

* [Buildroot] [PATCH v2 3/6] Add board files for snowball
From: Thomas Petazzoni @ 2012-11-12 18:37 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352742102-19010-4-git-send-email-gregory.hermant@calao-systems.com>

Dear Gregory Hermant,

On Mon, 12 Nov 2012 18:41:39 +0100, Gregory Hermant wrote:
> 
> Signed-off-by: Gregory Hermant <gregory.hermant@calao-systems.com>
> ---
>  board/calao/snowball/busybox-1.20.x.config | 1024 ++++++++++++++++++++++++++++

Is there a specific reason to have a custom Busybox configuration file?

Thanks,

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

^ permalink raw reply

* [Buildroot] [PATCH v2 1/6] hdmiservice: new package
From: Thomas Petazzoni @ 2012-11-12 18:34 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352742102-19010-2-git-send-email-gregory.hermant@calao-systems.com>

Dear Gregory Hermant,

On Mon, 12 Nov 2012 18:41:37 +0100, Gregory Hermant wrote:
> 
> Signed-off-by: Gregory Hermant <gregory.hermant@calao-systems.com>
> ---
>  package/Config.in                  |    1 +
>  package/hdmiservice/Config.in      |   10 +++++++++
>  package/hdmiservice/hdmiservice.mk |   43 ++++++++++++++++++++++++++++++++++++

Is this software something generic, or very specific to the Snowball
platform? I am worried by the package name that is way too generic for
something that looks board specific. It seems to be tied to a very
custom graphics driver.

> diff --git a/package/hdmiservice/hdmiservice.mk b/package/hdmiservice/hdmiservice.mk
> new file mode 100644
> index 0000000..7199f1c
> --- /dev/null
> +++ b/package/hdmiservice/hdmiservice.mk
> @@ -0,0 +1,43 @@
> +#############################################################
> +#
> +# hdmiservice
> +#
> +#############################################################
> +HDMISERVICE_VERSION = f75c99d1c52707240a78b4ba78e41d20d3aa3b08
> +HDMISERVICE_SITE = git://igloocommunity.org/git/bsp/hdmiservice.git
> +HDMISERVICE_LICENSE = MIT
> +HDMISERVICE_LICENSE_FILES = debian/copyright
> +HDMISERVICE_INSTALL_STAGING = YES
> +
> +define HDMISERVICE_BUILD_CMDS
> +	$(MAKE) CC="$(TARGET_CC)" -C $(@D)
> +endef
> +
> +define HDMISERVICE_INSTALL_STAGING_CMDS
> +	$(INSTALL) -D -m 0755 $(@D)/hdmiservice.so $(STAGING_DIR)/usr/lib/hdmiservice.so
> +	$(INSTALL) -D -m 0644 $(@D)/include/hdmi_service_api.h $(STAGING_DIR)/usr/include/hdmi_service_api.h
> +	$(INSTALL) -D -m 0644 $(@D)/include/hdmi_service_local.h $(STAGING_DIR)/usr/include/hdmi_service_local.h
> +endef
> +
> +define HDMISERVICE_INSTALL_TARGET_CMDS
> +	$(INSTALL) -D -m 0755 $(@D)/hdmiservice.so $(TARGET_DIR)/usr/lib/hdmiservice.so
> +	$(INSTALL) -D -m 0755 $(@D)/hdmistart $(TARGET_DIR)/usr/bin/hdmistart
> +endef

Any reason not to use the 'make install' target which apparently does
the right thing?

Thanks,

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

^ permalink raw reply

* [Buildroot] [PATCH v2 6/6] Add config file for the snowball board
From: Gregory Hermant @ 2012-11-12 17:41 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1352742102-19010-1-git-send-email-gregory.hermant@calao-systems.com>


Signed-off-by: Gregory Hermant <gregory.hermant@calao-systems.com>
---
 configs/calao_snowball_defconfig |   49 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 configs/calao_snowball_defconfig

diff --git a/configs/calao_snowball_defconfig b/configs/calao_snowball_defconfig
new file mode 100644
index 0000000..e5e67bf
--- /dev/null
+++ b/configs/calao_snowball_defconfig
@@ -0,0 +1,49 @@
+BR2_arm=y
+BR2_cortex_a9=y
+BR2_GCC_VERSION_4_7_X=y
+# BR2_SOFT_FLOAT is not set
+BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y
+BR2_TOOLCHAIN_BUILDROOT_INET_IPV6=y
+BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
+BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
+BR2_TOOLCHAIN_BUILDROOT_CXX=y
+BR2_VFP_FLOAT=y
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA2"
+BR2_PACKAGE_BUSYBOX_CONFIG="board/calao/snowball/busybox-1.20.x.config"
+BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
+BR2_PACKAGE_BZIP2=y
+BR2_PACKAGE_FBSET=y
+BR2_PACKAGE_FBTERM=y
+BR2_PACKAGE_HDMISERVICE=y
+BR2_PACKAGE_MINICOM=y
+BR2_PACKAGE_LUA=y
+BR2_PACKAGE_OPENSSL=y
+BR2_PACKAGE_SQLITE=y
+BR2_PACKAGE_JPEG=y
+BR2_PACKAGE_LIBPNG=y
+BR2_PACKAGE_LIBUNGIF=y
+BR2_PACKAGE_LIBELF=y
+BR2_PACKAGE_PCRE=y
+BR2_PACKAGE_LIBXML2=y
+BR2_PACKAGE_SNOWBALL_INIT=y
+BR2_PACKAGE_IW=y
+BR2_PACKAGE_WGET=y
+BR2_PACKAGE_WIRELESS_TOOLS=y
+BR2_PACKAGE_WIRELESS_TOOLS_LIB=y
+BR2_PACKAGE_WPA_SUPPLICANT=y
+BR2_PACKAGE_WPA_SUPPLICANT_EAP=y
+BR2_PACKAGE_WPA_SUPPLICANT_CLI=y
+BR2_PACKAGE_WPA_SUPPLICANT_PASSPHRASE=y
+BR2_PACKAGE_WPA_SUPPLICANT_AP_SUPPORT=y
+BR2_PACKAGE_WPA_SUPPLICANT_WPS=y
+BR2_TARGET_ROOTFS_TAR_GZIP=y
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BOARDNAME="snowball"
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_GIT=y
+BR2_LINUX_KERNEL_CUSTOM_GIT_REPO_URL="git://igloocommunity.org/git/kernel/igloo-kernel.git"
+BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="stable-linux-ux500-3.4"
+BR2_LINUX_KERNEL_PATCH="board/calao/snowball/"
+BR2_LINUX_KERNEL_DEFCONFIG="u8500"
+BR2_LINUX_KERNEL_INSTALL_TARGET=y
-- 
1.7.9.5

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox