* [Buildroot] [PATCH 08/14] polarssl: bump to version 1.2.3
From: Gustavo Zacarias @ 2012-12-03 14:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354545972-26783-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
.../polarssl-shared-and-static-library.patch | 10 +++++-----
| 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/package/polarssl/polarssl-shared-and-static-library.patch b/package/polarssl/polarssl-shared-and-static-library.patch
index e11cab3..ec65285 100644
--- a/package/polarssl/polarssl-shared-and-static-library.patch
+++ b/package/polarssl/polarssl-shared-and-static-library.patch
@@ -9,13 +9,13 @@ This patch adds the USE_STATIC_POLARSSL_LIBRARY (which defaults to ON)
in addition to the existing USE_SHARED_POLARSSL_LIBRARY (which
defaults to OFF). Both options can be manipulated independently.
-[Gustavo: update for polarssl 1.2.0]
+[Gustavo: update for polarssl 1.2.3]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
-diff -Nura polarssl-1.2.0.orig/library/CMakeLists.txt polarssl-1.2.0/library/CMakeLists.txt
---- polarssl-1.2.0.orig/library/CMakeLists.txt 2012-11-15 15:01:58.239248830 -0300
-+++ polarssl-1.2.0/library/CMakeLists.txt 2012-11-15 15:00:10.310806353 -0300
+diff -Nura polarssl-1.2.3.orig/library/CMakeLists.txt polarssl-1.2.3/library/CMakeLists.txt
+--- polarssl-1.2.3.orig/library/CMakeLists.txt 2012-11-27 17:16:20.735678722 -0300
++++ polarssl-1.2.3/library/CMakeLists.txt 2012-11-27 17:18:09.760457733 -0300
@@ -1,4 +1,5 @@
option(USE_SHARED_POLARSSL_LIBRARY "Build PolarSSL as a shared library." OFF)
+option(USE_STATIC_POLARSSL_LIBRARY "Build PolarSSL as a static library." ON)
@@ -34,7 +34,7 @@ diff -Nura polarssl-1.2.0.orig/library/CMakeLists.txt polarssl-1.2.0/library/CMa
+if(USE_SHARED_POLARSSL_LIBRARY)
add_library(polarssl SHARED ${src})
- set_target_properties(polarssl PROPERTIES VERSION 1.2.0 SOVERSION 2)
+ set_target_properties(polarssl PROPERTIES VERSION 1.2.3 SOVERSION 2)
+set_target_properties(polarssl PROPERTIES OUTPUT_NAME polarssl)
+
+endif(USE_SHARED_POLARSSL_LIBRARY)
--git a/package/polarssl/polarssl.mk b/package/polarssl/polarssl.mk
index edda9bf..c66c633 100644
--- a/package/polarssl/polarssl.mk
+++ b/package/polarssl/polarssl.mk
@@ -1,5 +1,5 @@
POLARSSL_SITE = https://polarssl.org/download
-POLARSSL_VERSION = 1.2.0
+POLARSSL_VERSION = 1.2.3
POLARSSL_SOURCE = polarssl-$(POLARSSL_VERSION)-gpl.tgz
POLARSSL_CONF_OPT = \
-DUSE_SHARED_POLARSSL_LIBRARY=ON \
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 07/14] ed: bump to version 1.7
From: Gustavo Zacarias @ 2012-12-03 14:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354545972-26783-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/ed/ed.mk | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/package/ed/ed.mk b/package/ed/ed.mk
index a97e19b..2bb8e0e 100644
--- a/package/ed/ed.mk
+++ b/package/ed/ed.mk
@@ -4,9 +4,11 @@
#
#############################################################
-ED_VERSION = 1.6
+ED_VERSION = 1.7
ED_SITE = $(BR2_GNU_MIRROR)/ed
ED_CONF_OPT = CC="$(TARGET_CC)" CFLAGS="$(TARGET_CFLAGS)" \
LDFLAGS="$(TARGET_LDFLAGS)"
+ED_LICENSE = GPLv3+
+ED_LICENSE_FILES = COPYING
$(eval $(autotools-package))
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 06/14] ipset: bump to version 6.16.1
From: Gustavo Zacarias @ 2012-12-03 14:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354545972-26783-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/ipset/ipset.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/ipset/ipset.mk b/package/ipset/ipset.mk
index 999c5cb..3ef9747 100644
--- a/package/ipset/ipset.mk
+++ b/package/ipset/ipset.mk
@@ -4,7 +4,7 @@
#
#############################################################
-IPSET_VERSION = 6.14
+IPSET_VERSION = 6.16.1
IPSET_SOURCE = ipset-$(IPSET_VERSION).tar.bz2
IPSET_SITE = http://ipset.netfilter.org
IPSET_DEPENDENCIES = libmnl host-pkgconf
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 05/14] php: bump to version 5.3.19
From: Gustavo Zacarias @ 2012-12-03 14:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354545972-26783-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/php/php.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/php/php.mk b/package/php/php.mk
index 0dfb6db..4290170 100644
--- a/package/php/php.mk
+++ b/package/php/php.mk
@@ -4,7 +4,7 @@
#
#############################################################
-PHP_VERSION = 5.3.18
+PHP_VERSION = 5.3.19
PHP_SOURCE = php-$(PHP_VERSION).tar.bz2
PHP_SITE = http://www.php.net/distributions
PHP_INSTALL_STAGING = YES
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 04/14] libnl: bump to version 3.2.16
From: Gustavo Zacarias @ 2012-12-03 14:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354545972-26783-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/libnl/libnl.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/libnl/libnl.mk b/package/libnl/libnl.mk
index e039fd4..9bf680e 100644
--- a/package/libnl/libnl.mk
+++ b/package/libnl/libnl.mk
@@ -4,7 +4,7 @@
#
#############################################################
-LIBNL_VERSION = 3.2.14
+LIBNL_VERSION = 3.2.16
LIBNL_SITE = http://www.infradead.org/~tgr/libnl/files
LIBNL_LICENSE = LGPLv2.1+
LIBNL_LICENSE_FILES = COPYING
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 03/14] radvd: bump to version 1.9.2
From: Gustavo Zacarias @ 2012-12-03 14:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354545972-26783-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/radvd/radvd-highjob.patch | 27 ---------------------------
package/radvd/radvd.mk | 2 +-
2 files changed, 1 insertions(+), 28 deletions(-)
delete mode 100644 package/radvd/radvd-highjob.patch
diff --git a/package/radvd/radvd-highjob.patch b/package/radvd/radvd-highjob.patch
deleted file mode 100644
index 5945435..0000000
--- a/package/radvd/radvd-highjob.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-From ce4911c13a3ab6877c0288c8a1874decb5d0e90a Mon Sep 17 00:00:00 2001
-From: Gustavo Zacarias <gustavo@zacarias.com.ar>
-Date: Mon, 23 Jul 2012 09:14:24 -0300
-Subject: [PATCH] Makefile: fix high jobcount build failures
-
-gram.h is a dependency for scanner.c rather than scanner.o which is
-unused.
-
-Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
----
- Makefile.am | 2 +-
- 1 files changed, 1 insertions(+), 1 deletions(-)
-
-diff --git a/Makefile.am b/Makefile.am
-index 04b834b..8a90ca7 100644
---- a/Makefile.am
-+++ b/Makefile.am
-@@ -131,5 +131,5 @@ dist-hook:
- rm -f $(distdir)/gram.h
- rm -f $(distdir)/scanner.c
-
--scanner.o: gram.h
-+scanner.c: gram.h
-
---
-1.7.8.6
-
diff --git a/package/radvd/radvd.mk b/package/radvd/radvd.mk
index 6151236..2a60729 100644
--- a/package/radvd/radvd.mk
+++ b/package/radvd/radvd.mk
@@ -4,7 +4,7 @@
#
#############################################################
-RADVD_VERSION = 1.9.1
+RADVD_VERSION = 1.9.2
RADVD_SITE = http://www.litech.org/radvd/dist
RADVD_DEPENDENCIES = flex libdaemon host-flex host-pkgconf
RADVD_AUTORECONF = YES
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 02/14] hdparm: bump to version 9.43
From: Gustavo Zacarias @ 2012-12-03 14:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354545972-26783-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/hdparm/hdparm.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/hdparm/hdparm.mk b/package/hdparm/hdparm.mk
index 76223f4..f70d232 100644
--- a/package/hdparm/hdparm.mk
+++ b/package/hdparm/hdparm.mk
@@ -4,7 +4,7 @@
#
#############################################################
-HDPARM_VERSION = 9.42
+HDPARM_VERSION = 9.43
HDPARM_SITE = http://downloads.sourceforge.net/project/hdparm/hdparm
HDPARM_LICENSE = BSD-Style
HDPARM_LICENSE_FILES = LICENSE.TXT
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 01/14] scons: bump to version 2.2.0
From: Gustavo Zacarias @ 2012-12-03 14:45 UTC (permalink / raw)
To: buildroot
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/scons/scons.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/scons/scons.mk b/package/scons/scons.mk
index d2489a0..79fd6b1 100644
--- a/package/scons/scons.mk
+++ b/package/scons/scons.mk
@@ -1,4 +1,4 @@
-SCONS_VERSION = 2.0.1
+SCONS_VERSION = 2.2.0
SCONS_SOURCE = scons-$(SCONS_VERSION).tar.gz
SCONS_SITE = http://downloads.sourceforge.net/project/scons/scons/$(SCONS_VERSION)
SCONS_LICENSE = MIT
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 10/13] Add update-all-config target
From: Stephan Hoffmann @ 2012-12-03 14:18 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAAXf6LWwO6OkBhz03vsBekTWv4=9Bb7eO-sskvzhdTCD58K7oA@mail.gmail.com>
Am 14.10.2012 20:45, schrieb Thomas De Schampheleire:
> Hi,
>
> On Sun, Oct 14, 2012 at 1:14 AM, Arnout Vandecappelle (Essensium/Mind)
> <arnout@mind.be> wrote:
>> > From: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>> >
>> > The update-all-config target updates all the external configuration
>> > file with their current values. This includes:
>> > - buildroot
>> > - busybox
>> > - linux
>> > - crosstool-ng
>> > - uClibc
>> >
>> > Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> I like this idea, and would propose to go through with this regardless
> of the outcome of the series.
> See below for some comments though
Hi,
I also like this idea much.
I'd like to go one step further and put buildroot's default config files
in the board/company/product hierarchy, too. Then everything would be in
one place.
This approach would be similar to that used by uClinux where all
relevant board specific files are in vendors/company/product.
Kind regards
Stephan
--
reLinux - Stephan Hoffmann
Am Schmidtgrund 124 50765 K?ln
Tel. +49.221.95595-19 Fax: -64
www.reLinux.de sho at reLinux.de
^ permalink raw reply
* [Buildroot] [PATCH] [RFC] new target: live filesystem
From: Jeremy Rosen @ 2012-12-03 13:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121203140758.25732492@skate>
> > +
> > +define ROOTFS_LIVE_CMD
> > + sudo rsync -a --no-o --no-g --delete-during $(TARGET_DIR)/
> > $(BR2_TARGET_ROOTFS_LIVE_DEST)/
> > +endef
>
> Do we really want to include sudo commands in Buildroot? I'm not sure
> we want.
that's the question I wanted answered by sending this patch early... I'm still quite new in this community and I am not sure how the buildroot philosophy is seen
note that I check for buildroot properly in the PRE_GEN_HOOKS and that I don't try to install host-sudo (which is not possible anyway)
I personally think that building target/ with sudo instead of fakeroot would be a stupid idea, but that's not what this patch does. This patch simply adds a new optional target to ease NFS deployment,
>
> What about instead a post-image script hook, that users can use to
> extract automatically the tarball image somewhere?
>
yes, that would work too, I can do that locally to solve my particular problem, but I don't think you would accept it upstream either. If you consider that deploying the live filesystem is not buildroot's job, fine I'll probably do it with post-build scripts instead, but I personally believe that NFS is the most common target and that doing it in buildroot-core is more convinient and makes more sense
pos-install scripts needs to be rewritten by each user, and doing it manually is a bit error prone (especially if you have lots of devs sharing a buildroot project through git, you can have weird side effects with people not cleaning before deplying the new FS)
again, I personally think this use-case makes sense, especially in big teams where some members don't want to learn what NFS is (yeah, sounds stupid, but it does happen) and I don't think there are any major drawback (we test sudo properly, we only call it for a specific use-case where it is really needed) except the philosophical question of "should a build tool use a tool giving root-priv like sudo" which in the case of NFS doesn't change much since the user will have to use it himself (either directly or trough post-image script).
I'd really think it makes sense in a "type make, reboot the target, test your change" philosophy which matches really well the idea behind NFS based developement, but it's your call as with any core change...
Regards
J?r?my
> 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] xtensa: add config option to enable longcalls option
From: Thomas Petazzoni @ 2012-12-03 13:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50bc6a34.45e8440a.493d.4091@mx.google.com>
Dear Chris Zankel,
On Mon, 3 Dec 2012 00:58:46 -0800, Chris Zankel wrote:
> The longcalls option allows calls across a greater range of addresses.
>
> This option should be used when call targets can potentially be
> out of range. It may degrade both code size and performance, but
> the linker can generally optimize away the unnecessary overhead
> when a call ends up within range.
>
> This option is enabled by default.
>
> Signed-off-by: Chris Zankel <chris@zankel.net>
> ---
> arch/Config.in.xtensa | 17 +++++++++++++++++
> package/Makefile.in | 6 ++++++
> 2 files changed, 23 insertions(+)
>
> diff --git a/arch/Config.in.xtensa b/arch/Config.in.xtensa
> index 60c03f5..a979108 100644
> --- a/arch/Config.in.xtensa
> +++ b/arch/Config.in.xtensa
> @@ -35,3 +35,20 @@ config BR2_XTENSA_OVERLAY_DIR
>
> config BR2_ARCH
> default "xtensa" if BR2_xtensa
> +
> +menu "Target build options"
> +
> +config BR2_XTENSA_LONGCALLS
> + bool "Enable longcalls option"
> + default y
> + help
> + Enable or disable transformation of call instructions to allow
> + calls across a greater range of addresses.
> + This option should be used when call targets can potentially be
> + out of range. It may degrade both code size and performance, but
> + the linker can generally optimize away the unnecessary overhead
> + when a call ends up within range.
> +
> + Should be enabled by default.
> +
> +endmenu
Do we really want that as a configurable option? Isn't it possible
instead to always generate longcalls, or to fix this on a per-package
basis, when needed?
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] [RFC] new target: live filesystem
From: Thomas Petazzoni @ 2012-12-03 13:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354531204-17481-1-git-send-email-jeremy.rosen@openwide.fr>
Dear J?r?my Rosen,
On Mon, 3 Dec 2012 11:40:03 +0100, J?r?my Rosen wrote:
> diff --git a/fs/live/live.mk b/fs/live/live.mk
> new file mode 100644
> index 0000000..33fe515
> --- /dev/null
> +++ b/fs/live/live.mk
> @@ -0,0 +1,20 @@
> +#############################################################
> +#
> +# Build the live root filesystem directory
> +#
> +#############################################################
> +
> +
> +define ROOTFS_LIVE_CMD
> + sudo rsync -a --no-o --no-g --delete-during $(TARGET_DIR)/ $(BR2_TARGET_ROOTFS_LIVE_DEST)/
> +endef
Do we really want to include sudo commands in Buildroot? I'm not sure
we want.
What about instead a post-image script hook, that users can use to
extract automatically the tarball image somewhere?
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] [RFC] new target: live filesystem
From: Jérémy Rosen @ 2012-12-03 10:40 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354003953-10875-1-git-send-email-jeremy.rosen@openwide.fr>
add a new target to deploy a live filesystem to be used with NFS or as a chroot
Signed-off-by: J?r?my Rosen <jeremy.rosen@openwide.fr>
---
v2 : implement Arnoult's suggestion, update manual entry
---
docs/manual/beyond-buildroot.txt | 16 +++++++---------
fs/Config.in | 1 +
fs/live/Config.in | 16 ++++++++++++++++
fs/live/live.mk | 20 ++++++++++++++++++++
4 files changed, 44 insertions(+), 9 deletions(-)
create mode 100644 fs/live/Config.in
create mode 100644 fs/live/live.mk
diff --git a/docs/manual/beyond-buildroot.txt b/docs/manual/beyond-buildroot.txt
index e7b902d..adf3e83 100644
--- a/docs/manual/beyond-buildroot.txt
+++ b/docs/manual/beyond-buildroot.txt
@@ -9,17 +9,15 @@ Boot the generated images
NFS boot
~~~~~~~~
-To achieve NFS-boot, enable _tar root filesystem_ in the _Filesystem
-images_ menu.
+To achieve NFS-boot, enable _live root filesystem_ in the _Filesystem
+images_ menu and select a _live image location_ to choose where the live
+filesystem will be deployed. you can use _$(BINARIES_DIR)_ to easily
+build in +/path/to/output_dir/+
-After a complete build, just run the following commands to setup the
-NFS-root directory:
+You will be asked for a password during the build. This is needed to create
+device entries in the target filesystem
--------------------
-sudo tar -xavf /path/to/output_dir/rootfs.tar -C /path/to/nfs_root_dir
--------------------
-
-Then, you can execute a NFS-boot from your target.
+You will need to add the target path to +/etc/exports+.
Chroot
------
diff --git a/fs/Config.in b/fs/Config.in
index 94154ea..de2377e 100644
--- a/fs/Config.in
+++ b/fs/Config.in
@@ -11,5 +11,6 @@ source "fs/cpio/Config.in"
source "fs/iso9660/Config.in"
source "fs/initramfs/Config.in"
source "fs/romfs/Config.in"
+source "fs/live/Config.in"
endmenu
diff --git a/fs/live/Config.in b/fs/live/Config.in
new file mode 100644
index 0000000..60d03a7
--- /dev/null
+++ b/fs/live/Config.in
@@ -0,0 +1,16 @@
+config BR2_TARGET_ROOTFS_LIVE
+ bool "live root filesystem"
+ help
+ uses sudo to create a live image of the filesystem
+ this is mainly useful if you want to use your filesystem
+ over NFS or a chroot
+config BR2_TARGET_ROOTFS_LIVE_DEST
+ string "live image location"
+ depends on BR2_TARGET_ROOTFS_LIVE
+ default "$(BINARIES_DIR)/live"
+ help
+ The directory where the image should be stored.
+ this directory will be emptied and recreated, it is given
+ relative to the buildroot output/images directory
+
+
diff --git a/fs/live/live.mk b/fs/live/live.mk
new file mode 100644
index 0000000..33fe515
--- /dev/null
+++ b/fs/live/live.mk
@@ -0,0 +1,20 @@
+#############################################################
+#
+# Build the live root filesystem directory
+#
+#############################################################
+
+
+define ROOTFS_LIVE_CMD
+ sudo rsync -a --no-o --no-g --delete-during $(TARGET_DIR)/ $(BR2_TARGET_ROOTFS_LIVE_DEST)/
+endef
+
+define ROOTFS_LIVE_INIT
+ if [ -z $(shell which sudo) ] ; then echo "sudo seems to not be installed on the host system" ; false ; fi ; \
+ if [ ! -t 0 ] ; then echo "live filesystem must be generated interactively" ; false ; fi ; \
+ if [ ! -t 2 ] ; then echo "live filesystem must be generated interactively" ; false ; fi ;
+endef
+
+ROOTFS_LIVE_PRE_GEN_HOOKS += ROOTFS_LIVE_INIT
+
+$(eval $(call ROOTFS_TARGET,live))
--
1.7.10.4
^ permalink raw reply related
* [Buildroot] [PATCH] reorder fs alphabetically
From: Jeremy Rosen @ 2012-12-03 10:30 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354530109-13231-1-git-send-email-jeremy.rosen@openwide.fr>
Oops, I didn't intend to resent that patch, I wasn't on the correct branch
sorry about that
Cordialement
J?r?my Rosen
fight key loggers : write some perl using vim
----- Mail original -----
> De: "J?r?my Rosen" <jeremy.rosen@openwide.fr>
> ?: buildroot at busybox.net
> Cc: "J?r?my Rosen" <jeremy.rosen@openwide.fr>
> Envoy?: Lundi 3 D?cembre 2012 11:21:49
> Objet: [PATCH] reorder fs alphabetically
>
> Signed-off-by: J?r?my Rosen <jeremy.rosen@openwide.fr>
> ---
> fs/Config.in | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/fs/Config.in b/fs/Config.in
> index 94154ea..da4c5ff 100644
> --- a/fs/Config.in
> +++ b/fs/Config.in
> @@ -1,15 +1,15 @@
> menu "Filesystem images"
>
> -source "fs/cramfs/Config.in"
> source "fs/cloop/Config.in"
> +source "fs/cpio/Config.in"
> +source "fs/cramfs/Config.in"
> source "fs/ext2/Config.in"
> +source "fs/initramfs/Config.in"
> +source "fs/iso9660/Config.in"
> source "fs/jffs2/Config.in"
> -source "fs/ubifs/Config.in"
> +source "fs/romfs/Config.in"
> source "fs/squashfs/Config.in"
> source "fs/tar/Config.in"
> -source "fs/cpio/Config.in"
> -source "fs/iso9660/Config.in"
> -source "fs/initramfs/Config.in"
> -source "fs/romfs/Config.in"
> +source "fs/ubifs/Config.in"
>
> endmenu
> --
> 1.7.10.4
>
>
^ permalink raw reply
* [Buildroot] [PATCH] reorder fs alphabetically
From: Jérémy Rosen @ 2012-12-03 10:21 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354003953-10875-1-git-send-email-jeremy.rosen@openwide.fr>
Signed-off-by: J?r?my Rosen <jeremy.rosen@openwide.fr>
---
fs/Config.in | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/Config.in b/fs/Config.in
index 94154ea..da4c5ff 100644
--- a/fs/Config.in
+++ b/fs/Config.in
@@ -1,15 +1,15 @@
menu "Filesystem images"
-source "fs/cramfs/Config.in"
source "fs/cloop/Config.in"
+source "fs/cpio/Config.in"
+source "fs/cramfs/Config.in"
source "fs/ext2/Config.in"
+source "fs/initramfs/Config.in"
+source "fs/iso9660/Config.in"
source "fs/jffs2/Config.in"
-source "fs/ubifs/Config.in"
+source "fs/romfs/Config.in"
source "fs/squashfs/Config.in"
source "fs/tar/Config.in"
-source "fs/cpio/Config.in"
-source "fs/iso9660/Config.in"
-source "fs/initramfs/Config.in"
-source "fs/romfs/Config.in"
+source "fs/ubifs/Config.in"
endmenu
--
1.7.10.4
^ permalink raw reply related
* [Buildroot] [PATCH] reorder fs alphabetically
From: Jeremy Rosen @ 2012-12-03 10:20 UTC (permalink / raw)
To: buildroot
In-Reply-To: <87a9tvpppm.fsf@dell.be.48ers.dk>
hmm, I can't see it, was it applied to master or next ? (trying to clean up my local branches here, no big deal...)
Regards
J?r?my Rosen
fight key loggers : write some perl using vim
----- Mail original -----
> De: "Peter Korsgaard" <jacmet@uclibc.org>
> ?: "J?r?my Rosen" <jeremy.rosen@openwide.fr>
> Cc: buildroot at busybox.net
> Envoy?: Lundi 3 D?cembre 2012 08:19:49
> Objet: Re: [PATCH] reorder fs alphabetically
>
> >>>>> "J?r?my" == J?r?my Rosen <jeremy.rosen@openwide.fr> writes:
>
> J?r?my> Signed-off-by: J?r?my Rosen <jeremy.rosen@openwide.fr>
>
> Committed, thanks.
>
> --
> Bye, Peter Korsgaard
>
^ permalink raw reply
* [Buildroot] [PATCH] make legal-info: fails with OVERRIDE_SRCDIR
From: Stephan Hoffmann @ 2012-12-03 10:05 UTC (permalink / raw)
To: buildroot
There is a check for OVERRIDE_SRCDIR in pkg-generic.mk that is
supposed to produce a warning when OVERRIDE_SRCDIR is active.
This does not work and instead the whole make terminates with
an error message.
This patch changes the check for active OVERRIDE_SRCDIR so that
it works as expected.
Signed-off-by: Stephan Hoffmann <sho@relinux.de>
---
package/pkg-generic.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index 9c4fffa..d6bcb67 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -479,7 +479,7 @@ ifneq ($(call qstrip,$$($(2)_SOURCE)),)
ifeq ($$($(2)_SITE_METHOD),local)
# Packages without a tarball: don't save and warn
@$(call legal-warning-pkg-savednothing,$$($(2)_RAWNAME),local)
-else ifeq ($$($(2)_SITE_METHOD),override)
+else ifneq ($$($(2)_OVERRIDE_SRCDIR),)
@$(call legal-warning-pkg-savednothing,$$($(2)_RAWNAME),override)
else
# Other packages
--
1.7.0.4
^ permalink raw reply related
* [Buildroot] [PATCH] pkg-infra: rename <pkg>-rsync to <pkg>-extract
From: Stephan Hoffmann @ 2012-12-03 9:58 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A3545F.2090602@relinux.de>
Am 14.11.2012 09:20, schrieb Stephan Hoffmann:
> Am 14.11.2012 00:48, schrieb Arnout Vandecappelle:
>> On 12/11/12 09:27, Stephan Hoffmann wrote:
>>> Am 14.10.2012 16:41, schrieb Arnout Vandecappelle (Essensium/Mind):
>> [snip]
>>>> +$(1)-extract: $$($(2)_TARGET_RSYNC)
>>>>
>>>> $(1)-source: $$($(2)_TARGET_RSYNC_SOURCE)
>>>> endif
>>> Hello,
>>>
>>> this does not fix my issue, not even after doing a "make clean".
>> [snip]
>>>>>>> linux custom Syncing from source dir
>>>> /home/stephan/Dokumente/BeagleBone/kernel/kernel
>>>> rsync -au /home/stephan/Dokumente/BeagleBone/kernel/kernel/
>>>> /home/stephan/Dokumente/BeagleBone/buildroot/output/build/linux-custom
>>>> cp: cannot stat `/home/stephan/Dokumente/dl/linux-custom.tar.gz': No
>>>> such file or directory
>>>> make: *** [linux-legal-info] Error 1
>> One step at a time :-)
>>
>> The .tar.gz doesn't exist for overridden packages. So what should we
>> do -
>> exclude the source for overridden packages?
> Good point. At the first glance, I'd suggest to create the tar.gz using
> the x_OVERRIDE_SRCDIR. That seems to be better than nothing.
>
> After creating a linux-custom.tar.gz, "make legal-info" works for me,
> but it does not seem to make sence to copy a .tar.gz file that has not
> been extracted to build the packet.
Hello,
I just started looking at this again and found in package/pkg-generic.mk:
> # legal-info: produce legally relevant info.
> $(1)-legal-info:
> # Packages without a source are assumed to be part of Buildroot, skip
> them.
> ifneq ($(call qstrip,$$($(2)_SOURCE)),)
> ifeq ($$($(2)_SITE_METHOD),local)
> # Packages without a tarball: don't save and warn
> @$(call legal-warning-pkg-savednothing,$$($(2)_RAWNAME),local)
> else ifeq ($$($(2)_SITE_METHOD),override)
> @$(call legal-warning-pkg-savednothing,$$($(2)_RAWNAME),override)
> else
So there should just be a warning, but no make failing. Obviously, the
test for "override" does not work as expected. A patch changing this to
ifneq ($$($(2)_OVERRIDE_SRCDIR),)
follows, but I do not think that SITE_METHOD ever gets set to "override"
at all. So other parts of pkg-generic.mk might also need a closer look.
> Kind regards
>
> Stephan
>> Regards,
>> Arnout
>>
>
--
reLinux - Stephan Hoffmann
Am Schmidtgrund 124 50765 K?ln
Tel. +49.221.95595-19 Fax: -64
www.reLinux.de sho at reLinux.de
^ permalink raw reply
* [Buildroot] Buildroot 2012.11 released
From: Arnout Vandecappelle @ 2012-12-03 9:39 UTC (permalink / raw)
To: buildroot
In-Reply-To: <87vcck545l.fsf@dell.be.48ers.dk>
On 03/12/12 02:13, Peter Korsgaard wrote:
> Buildroot 2012.11 is released
Congratulations, Peter, and thanks for spending this effort to get the
release out!
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] [git commit] libtool: undeprecate for now
From: Arnout Vandecappelle @ 2012-12-03 9:31 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121203092529.05e8d34c@skate>
On 03/12/12 09:25, Thomas Petazzoni wrote:
> Dear Peter Korsgaard,
>
> On Sun, 2 Dec 2012 16:31:54 -0800, Peter Korsgaard wrote:
>> commit: http://git.buildroot.net/buildroot/commit/?id=f619d5ba20ef46c57259f35a21bb98b7c85c35a4
>> branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
>>
>> Pulseaudio selects libtool, so get rid of the deprecated annotation so
>> people don't get warnings about unmet dependencies when exiting menuconfig.
>
> Pulseaudio needs libtool on the target? This sounds strange, no?
It needs libltdl, I guess to read .la files for plugins. That said, I wonder if
it even works since we remove the .la files... I started to look at it a while
ago but never got anywhere.
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] [PATCH][RFC] new target: live filesystem
From: Samuel Martin @ 2012-12-03 9:21 UTC (permalink / raw)
To: buildroot
In-Reply-To: <2f772bd2-fecd-4aeb-9bbe-83316ac7deed@zimbra2.corp.accelance.fr>
Hi Jeremy, all,
2012/12/3 Jeremy Rosen <jeremy.rosen@openwide.fr>:
> well, it's more a question of what you consider the live filesystem to be...
>
> I see it a as just another filesystem format (basically a NFS target) which is why my original patch had it in output/images/live
>
> if you see it as a deployment, it does not really make sense to add it to buildroot (buildroot doesn't flash the filesystem directly) I can understand that both point of view make sense
>
> however having this target makes things simpler in a very common use case (arguably the most common use case since it's the case where you use buildroot repeatedly to prepare the fs, not the case where you run it once to build the final FS)
That's a controversial topic...
But, at least, you cat start filling the gap in the doc ;-),
especially this section:
http://buildroot.org/downloads/manual/manual.html#_beyond_buildroot
--
Sam
^ permalink raw reply
* [Buildroot] [PATCH v2] xtensa: add config option to enable longcalls option
From: Chris Zankel @ 2012-12-03 8:58 UTC (permalink / raw)
To: buildroot
The longcalls option allows calls across a greater range of addresses.
This option should be used when call targets can potentially be
out of range. It may degrade both code size and performance, but
the linker can generally optimize away the unnecessary overhead
when a call ends up within range.
This option is enabled by default.
Signed-off-by: Chris Zankel <chris@zankel.net>
---
arch/Config.in.xtensa | 17 +++++++++++++++++
package/Makefile.in | 6 ++++++
2 files changed, 23 insertions(+)
diff --git a/arch/Config.in.xtensa b/arch/Config.in.xtensa
index 60c03f5..a979108 100644
--- a/arch/Config.in.xtensa
+++ b/arch/Config.in.xtensa
@@ -35,3 +35,20 @@ config BR2_XTENSA_OVERLAY_DIR
config BR2_ARCH
default "xtensa" if BR2_xtensa
+
+menu "Target build options"
+
+config BR2_XTENSA_LONGCALLS
+ bool "Enable longcalls option"
+ default y
+ help
+ Enable or disable transformation of call instructions to allow
+ calls across a greater range of addresses.
+ This option should be used when call targets can potentially be
+ out of range. It may degrade both code size and performance, but
+ the linker can generally optimize away the unnecessary overhead
+ when a call ends up within range.
+
+ Should be enabled by default.
+
+endmenu
diff --git a/package/Makefile.in b/package/Makefile.in
index 9fdc745..b52d5e0 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -56,6 +56,12 @@ TARGET_ABI+=-mabi=spe -mfloat-gprs=double -Wa,-me500mc
endif
endif
+# Xtensa: The 'longcalls' option is required for large binary packages.
+# Use a global option for all packages for now.
+ifeq ($(BR2_XTENSA_LONGCALLS),y)
+TARGET_CFLAGS += -mlongcalls
+endif
+
STAGING_DIR=$(HOST_DIR)/usr/$(GNU_TARGET_NAME)/sysroot
TARGET_OPTIMIZATION:=$(call qstrip,$(BR2_TARGET_OPTIMIZATION))
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] [PATCH] [PATCH][RFC] new target: live filesystem
From: Jeremy Rosen @ 2012-12-03 8:57 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAJJ6jxvVkLmLmMiC+3bKEqokBUd1-LrJ8nJywzYmtVYxbXsSNQ@mail.gmail.com>
well, it's more a question of what you consider the live filesystem to be...
I see it a as just another filesystem format (basically a NFS target) which is why my original patch had it in output/images/live
if you see it as a deployment, it does not really make sense to add it to buildroot (buildroot doesn't flash the filesystem directly) I can understand that both point of view make sense
however having this target makes things simpler in a very common use case (arguably the most common use case since it's the case where you use buildroot repeatedly to prepare the fs, not the case where you run it once to build the final FS)
yes it's a two line script, and yes it's a minor change, but I think it makes sense and it's simple enough for it not to be a big deal...
Regards
J?r?my Rosen
fight key loggers : write some perl using vim
----- Mail original -----
> De: "Steve Calfee" <stevecalfee@gmail.com>
> ?: "Arnout Vandecappelle" <arnout@mind.be>
> Cc: "J?r?my Rosen" <jeremy.rosen@openwide.fr>, buildroot at busybox.net
> Envoy?: Vendredi 30 Novembre 2012 22:46:53
> Objet: Re: [Buildroot] [PATCH] [PATCH][RFC] new target: live filesystem
>
> On Fri, Nov 30, 2012 at 1:15 AM, Arnout Vandecappelle
> <arnout@mind.be> wrote:
> > On 30/11/12 01:04, Steve Calfee wrote:
> >>
> >> I don't understand why you need this. It is a one line "sudo tar
> >> -xf
> >> ..." to unpack the tarball into your nfs directory. Either type
> >> this
> >> line or add a one line script to your ~/bin directory to do it for
> >> each of your buildroot trees/environments. Don't add clutter to
> >> the
> >> buildroot makefile.
> >
> >
> > If that is the reasoning, we can also remove the compression of
> > the
> > .tar file, or the -dirclean targets, etc. etc.
> >
> > In addition, this target also cleans up the NFS directory first,
> > so
> > it's slightly more than just untarring.
> >
> Hi Arnout,
>
> I guess, but buildroot is all about building, not deploying. What is
> next, an automatic copy to my usb or sd drive? Stuff that is highly
> user specific should not be in the makefile, especially stuff that
> can
> easily be added to a simple script - my opinion only,
>
> Steve
>
^ permalink raw reply
* [Buildroot] Problem with NFS boot
From: Thomas Petazzoni @ 2012-12-03 8:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CADKZYYLt90YY8rm4SCuqRN2SsAGqjXhQM7t5hQydpV9o7ZtT+A@mail.gmail.com>
Dear Santhosh Ramani,
On Sat, 1 Dec 2012 19:51:37 -0600, Santhosh Ramani wrote:
> Thank you for your reply, yes I did untar the rootfs.tar.bz2 into the
> folder that is exported as NFS using sudo.
>
> Note:
> Linux kernel from TI SDK + buildroot rootfs = no nfs (only SD Card)
> Linux kernle from buildroot + buildroot rootfs = everything works fine.
What /dev management solution are you using? Static? Dynamic?
If you're using one of the dynamic solutions (devtmpfs, mdev or udev),
make sure that your kernel is built with CONFIG_DEVTMPFS and
CONFIG_DEVTMPFS_MOUNT. When the kernel is built by Buildroot, Buildroot
automatically enables those options. When your kernel is built
manually, you have to make sure those options are enabled.
Best regards,
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] [git commit] libtool: undeprecate for now
From: Thomas Petazzoni @ 2012-12-03 8:25 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121203010304.2A651996F6@busybox.osuosl.org>
Dear Peter Korsgaard,
On Sun, 2 Dec 2012 16:31:54 -0800, Peter Korsgaard wrote:
> commit: http://git.buildroot.net/buildroot/commit/?id=f619d5ba20ef46c57259f35a21bb98b7c85c35a4
> branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
>
> Pulseaudio selects libtool, so get rid of the deprecated annotation so
> people don't get warnings about unmet dependencies when exiting menuconfig.
Pulseaudio needs libtool on the target? This sounds strange, no?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox