* [Buildroot] [git commit] linux: bump 3.6.x stable version
From: Peter Korsgaard @ 2012-12-04 18:52 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=2422f13aaf6909d22414dba2fd8722135b1bb02b
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
linux/Config.in | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/linux/Config.in b/linux/Config.in
index f408ad5..ef3b2a1 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -21,7 +21,7 @@ choice
prompt "Kernel version"
config BR2_LINUX_KERNEL_3_6
- bool "3.6.8"
+ bool "3.6.9"
config BR2_LINUX_KERNEL_SAME_AS_HEADERS
bool "Same as toolchain kernel headers"
@@ -76,7 +76,7 @@ config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION
config BR2_LINUX_KERNEL_VERSION
string
- default "3.6.8" if BR2_LINUX_KERNEL_3_6
+ default "3.6.9" if BR2_LINUX_KERNEL_3_6
default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS
default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION
default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL
^ permalink raw reply related
* [Buildroot] [git commit] kernel-headers: bump 3.{0, 4, 6}.x stable versions
From: Peter Korsgaard @ 2012-12-04 18:52 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=261f894bb8633646162280f5a9ac1a9abb12a2e5
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
| 6 +++---
...all-fix-__packed-in-exported-kernel-head.patch} | 0
2 files changed, 3 insertions(+), 3 deletions(-)
--git a/toolchain/kernel-headers/Config.in b/toolchain/kernel-headers/Config.in
index 12b3956..6552c62 100644
--- a/toolchain/kernel-headers/Config.in
+++ b/toolchain/kernel-headers/Config.in
@@ -67,12 +67,12 @@ config BR2_DEFAULT_KERNEL_HEADERS
default "2.6.37.6" if BR2_KERNEL_HEADERS_2_6_37
default "2.6.38.8" if BR2_KERNEL_HEADERS_2_6_38
default "2.6.39.4" if BR2_KERNEL_HEADERS_2_6_39
- default "3.0.53" if BR2_KERNEL_HEADERS_3_0
+ default "3.0.54" if BR2_KERNEL_HEADERS_3_0
default "3.1.10" if BR2_KERNEL_HEADERS_3_1
default "3.2.34" if BR2_KERNEL_HEADERS_3_2
default "3.3.8" if BR2_KERNEL_HEADERS_3_3
- default "3.4.20" if BR2_KERNEL_HEADERS_3_4
+ default "3.4.21" if BR2_KERNEL_HEADERS_3_4
default "3.5.7" if BR2_KERNEL_HEADERS_3_5
- default "3.6.8" if BR2_KERNEL_HEADERS_3_6
+ default "3.6.9" if BR2_KERNEL_HEADERS_3_6
default "2.6" if BR2_KERNEL_HEADERS_SNAP
default $BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION
diff --git a/toolchain/kernel-headers/linux-3.0.53-headers_install-fix-__packed-in-exported-kernel-head.patch b/toolchain/kernel-headers/linux-3.0.54-headers_install-fix-__packed-in-exported-kernel-head.patch
similarity index 100%
rename from toolchain/kernel-headers/linux-3.0.53-headers_install-fix-__packed-in-exported-kernel-head.patch
rename to toolchain/kernel-headers/linux-3.0.54-headers_install-fix-__packed-in-exported-kernel-head.patch
^ permalink raw reply related
* [Buildroot] [git commit] dependencies.sh: check for java tools if classpath is enabled
From: Peter Korsgaard @ 2012-12-04 18:28 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=4be86184e032652863ea826edb9018f5f9b64b7d
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
support/dependencies/dependencies.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/support/dependencies/dependencies.sh b/support/dependencies/dependencies.sh
index 9f0f6a9..1b79b23 100755
--- a/support/dependencies/dependencies.sh
+++ b/support/dependencies/dependencies.sh
@@ -158,3 +158,11 @@ if grep ^BR2_TOOLCHAIN_BUILDROOT=y $CONFIG_FILE > /dev/null && \
exit 1 ;
fi
fi
+if grep -q ^BR2_PACKAGE_CLASSPATH=y $CONFIG_FILE ; then
+ for prog in java javac jar; do
+ if ! which $prog > /dev/null ; then
+ /bin/echo -e "\nYou must install '$prog' on your build machine\n" >&2
+ exit 1
+ fi
+ done
+fi
^ permalink raw reply related
* [Buildroot] [git commit] package: add jamvm jvm
From: Peter Korsgaard @ 2012-12-04 18:21 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=ae10e33a504770b0141dd7582c6ca26fc43b4642
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/Config.in | 1 +
package/jamvm/Config.in | 9 +++++++++
package/jamvm/jamvm.mk | 11 +++++++++++
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/package/Config.in b/package/Config.in
index 66e8352..f95e29d 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -268,6 +268,7 @@ endmenu
menu "Interpreter languages and scripting"
source "package/erlang/Config.in"
source "package/haserl/Config.in"
+source "package/jamvm/Config.in"
source "package/lua/Config.in"
source "package/luajit/Config.in"
if BR2_PACKAGE_LUA || BR2_PACKAGE_LUAJIT
diff --git a/package/jamvm/Config.in b/package/jamvm/Config.in
new file mode 100644
index 0000000..852c6e8
--- /dev/null
+++ b/package/jamvm/Config.in
@@ -0,0 +1,9 @@
+config BR2_PACKAGE_JAMVM
+ bool "jamvm"
+ select BR2_PACKAGE_ZLIB
+ select BR2_PACKAGE_CLASSPATH
+ help
+ JamVM is a new Java Virtual Machine which conforms to the
+ JVM specification version 2 (blue book).
+
+ http://jamvm.sf.net
diff --git a/package/jamvm/jamvm.mk b/package/jamvm/jamvm.mk
new file mode 100644
index 0000000..f0765d7
--- /dev/null
+++ b/package/jamvm/jamvm.mk
@@ -0,0 +1,11 @@
+JAMVM_VERSION = 1.5.4
+JAMVM_SITE = http://downloads.sourceforge.net/project/jamvm/jamvm/JamVM%20$(JAMVM_VERSION)
+JAMVM_DEPENDENCIES = zlib classpath
+# int inlining seems to crash jamvm, don't build shared version of internal lib
+JAMVM_CONF_OPT = \
+ --with-classpath-install-dir=/usr \
+ --disable-int-inlining \
+ --disable-shared \
+ --without-pic
+
+$(eval $(autotools-package))
^ permalink raw reply related
* [Buildroot] [git commit] package: add classpath
From: Peter Korsgaard @ 2012-12-04 18:21 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=5062f530081913bd0487f0f879be180f30836ab8
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Requires java, javac and jar on the build machine, similar to how we
require gcc/g++.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
classpath: fixup
---
package/Config.in | 1 +
package/classpath/Config.in | 14 ++++++++++
package/classpath/classpath.mk | 55 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/package/Config.in b/package/Config.in
index 5ba1f05..66e8352 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -489,6 +489,7 @@ endmenu
menu "Other"
source "package/apr/Config.in"
source "package/apr-util/Config.in"
+source "package/classpath/Config.in"
source "package/fftw/Config.in"
source "package/libargtable2/Config.in"
source "package/argp-standalone/Config.in"
diff --git a/package/classpath/Config.in b/package/classpath/Config.in
new file mode 100644
index 0000000..45d5984
--- /dev/null
+++ b/package/classpath/Config.in
@@ -0,0 +1,14 @@
+config BR2_PACKAGE_CLASSPATH
+ bool "classpath"
+ depends on BR2_PACKAGE_JAMVM
+ depends on BR2_INET_IPV6
+ help
+ GNU Classpath, Essential Libraries for Java, is a GNU
+ project to create free core class libraries for use with
+ virtual machines and compilers for the java programming
+ language.
+
+ http://classpath.org
+
+comment "classpath requires a toolchain with IPV6 support"
+ depends on !BR2_INET_IPV6
diff --git a/package/classpath/classpath.mk b/package/classpath/classpath.mk
new file mode 100644
index 0000000..9142f69
--- /dev/null
+++ b/package/classpath/classpath.mk
@@ -0,0 +1,55 @@
+CLASSPATH_VERSION = 0.98
+CLASSPATH_SITE = $(BR2_GNU_MIRROR)/classpath
+CLASSPATH_CONF_OPT = \
+ --disable-examples \
+ --disable-plugin \
+ --disable-rpath \
+ --disable-Werror \
+ --disable-gconf-peer \
+ --disable-tools
+
+CLASSPATH_DEPENDENCIES = host-pkgconf
+
+ifeq ($(BR2_PACKAGE_ALSA_LIB),y)
+CLASSPATH_CONF_OPT += --enable-alsa
+CLASSPATH_DEPENDENCIES += alsa-lib
+else
+CLASSPATH_CONF_OPT += --disable-alsa
+endif
+
+ifeq ($(BR2_PACKAGE_GMP),y)
+CLASSPATH_CONF_OPT += --enable-gmp
+CLASSPATH_DEPENDENCIES += gmp
+else
+CLASSPATH_CONF_OPT += --disable-gmp
+endif
+
+ifeq ($(BR2_PACKAGE_GST_PLUGINS_BASE),y)
+CLASSPATH_CONF_OPT += --enable-gstreamer-peer
+CLASSPATH_DEPENDENCIES += gst-plugins-base
+else
+CLASSPATH_CONF_OPT += --disable-gstreamer-peer
+endif
+
+ifeq ($(BR2_PACKAGE_LIBGTK2)$(BR2_PACKAGE_XORG7),yy)
+CLASSPATH_CONF_OPT += --enable-gtk-peer
+CLASSPATH_DEPENDENCIES += libgtk2
+else
+CLASSPATH_CONF_OPT += --disable-gtk-peer
+endif
+
+ifeq ($(BR2_PACKAGE_QT),y)
+CLASSPATH_CONF_OPT += --enable-qt-peer
+CLASSPATH_DEPENDENCIES += qt
+else
+CLASSPATH_CONF_OPT += --disable-qt-peer
+endif
+
+ifeq ($(BR2_PACKAGE_LIBXML2)$(BR2_PACKAGE_LIBXSLT),yy)
+CLASSPATH_CONF_OPT += --enable-xmlj
+CLASSPATH_DEPENDENCIES += libxml2 libxslt
+else
+CLASSPATH_CONF_OPT += --disable-xmlj
+endif
+
+$(eval $(autotools-package))
^ permalink raw reply related
* [Buildroot] How to handle modularity in buildroot?
From: Charles Manning @ 2012-12-04 18:18 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121204101042.3ae057bb@skate>
On Tue, Dec 4, 2012 at 10:10 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Charles Manning,
>
> On Tue, 4 Dec 2012 12:49:14 +1300, Charles Manning wrote:
>
>> I am aware of this mechanism but I don't think it really gets me what I am
>> after.
>>
>> I think that with defconfig, I would be able to make defconfig, then tweak the
>> config to get a variant. But now if I change the base config, I then have to
>> go through the process again for the variant.
>>
>> What I would like is the ability to have:
>> * A base package
>> * Production rootfs = base + production files.
>> * Development rootfs = base + development files.
>>
>> Then a change to the base package automatically flows through the production +
>> development rootfs.
>>
>> Is there a way to accomplish that?
>
> First of all, thanks for your nice words about Buildroot, definitely
> appreciated.
>
> That said, if Buildroot is certainly simpler than OE, it also means
> that Buildroot has a smaller feature set, and to some extent a bit less
> flexibility.
Thanks Thomas
I certainly would never want buildroot to bloat out to be like OE. The
most direct way to make something useless is to try to be all o be all
things to all people.
buildroot is very valuable and I intend to contribute where I can. I
live in New Zealand which makes it a bit hard to attend FOSDEM :-).
>
> What you can do to achieve what you want is use defconfig fragments.
> For example:
>
> * mysystem_base_defconfig.frag would contain:
>
> BR2_arm=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
> BR2_TOOLCHAIN_EXTERNAL_PATH="/home/thomas/x-tools/arm-br-arm926/usr/"
> BR2_TOOLCHAIN_EXTERNAL_LARGEFILE=y
> BR2_TOOLCHAIN_EXTERNAL_INET_IPV6=y
> BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
> # BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
> BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
> BR2_TOOLCHAIN_EXTERNAL_CXX=y
> BR2_PACKAGE_BUSYBOX=y
>
> * mysystem_prod_defconfig.frag would contain:
>
> BR2_PACKAGE_APPLICATION1=y
> BR2_PACKAGE_APPLICATION2=y
>
> * mysystem_dev_defconfig.frag would contain:
>
> BR2_PACKAGE_STRACE=y
> BR2_PACKAGE_LTRACE=y
>
> And then, when you want to do a production build:
>
> make clean
> cat mysystem_base_defconfig.frag mysystem_prod_defconfig.frag > configs/mysystem_prod_defconfig
> make mysystem_prod_defconfig
> make
>
> And when you want to do a development build:
>
> make clean
> cat mysystem_base_defconfig.frag mysystem_dev_defconfig.frag > configs/mysystem_dev_defconfig
> make mysystem_dev_defconfig
> make
>
> Basically, instead of having Buildroot providing this feature, we rely
> on the simple manipulation of the configuration file.
This sounds like the right idea.
I will experiment with this a bit and see where it takes me. If there
is something worth sharing I'll do that.
Thanks
Charles
^ permalink raw reply
* [Buildroot] [PATCH 2/2] usb_modeswitch_data: bump to version 20121109
From: Gustavo Zacarias @ 2012-12-04 18:13 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354644802-28286-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/usb_modeswitch_data/usb_modeswitch_data.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/usb_modeswitch_data/usb_modeswitch_data.mk b/package/usb_modeswitch_data/usb_modeswitch_data.mk
index a7b7072..479137c 100644
--- a/package/usb_modeswitch_data/usb_modeswitch_data.mk
+++ b/package/usb_modeswitch_data/usb_modeswitch_data.mk
@@ -4,7 +4,7 @@
#
#############################################################
-USB_MODESWITCH_DATA_VERSION = 20120815
+USB_MODESWITCH_DATA_VERSION = 20121109
USB_MODESWITCH_DATA_SOURCE = usb-modeswitch-data-$(USB_MODESWITCH_DATA_VERSION).tar.bz2
USB_MODESWITCH_DATA_SITE = http://www.draisberghof.de/usb_modeswitch
USB_MODESWITCH_DATA_DEPENDENCIES = usb_modeswitch
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] usb_modeswitch: bump to version 1.2.5
From: Gustavo Zacarias @ 2012-12-04 18:13 UTC (permalink / raw)
To: buildroot
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/usb_modeswitch/usb_modeswitch.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/usb_modeswitch/usb_modeswitch.mk b/package/usb_modeswitch/usb_modeswitch.mk
index c517991..653109d 100644
--- a/package/usb_modeswitch/usb_modeswitch.mk
+++ b/package/usb_modeswitch/usb_modeswitch.mk
@@ -4,7 +4,7 @@
#
#############################################################
-USB_MODESWITCH_VERSION = 1.2.4
+USB_MODESWITCH_VERSION = 1.2.5
USB_MODESWITCH_SOURCE = usb-modeswitch-$(USB_MODESWITCH_VERSION).tar.bz2
USB_MODESWITCH_SITE = http://www.draisberghof.de/usb_modeswitch
USB_MODESWITCH_DEPENDENCIES = libusb-compat
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH] package/crosstool-ng: update to 1.17.0
From: Yann E. MORIN @ 2012-12-04 18:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121204101228.2e78f9a1@skate>
Thomas, Carsten, All,
On Tuesday 04 December 2012 Thomas Petazzoni wrote:
> On Mon, 3 Dec 2012 20:47:45 +0100, Carsten Schoenert wrote:
> > From: Carsten Schoenert <c.schoenert@t-online.de>
> >
> > Updating current crosstool-ng config files to 1.17.0
> > crosstool-ng.config-eglibc
> > crosstool-ng.config-glibc
> > crosstool-ng.config-uClibc
> >
> > Signed-off-by: Carsten Schoenert <c.schoenert@t-online.de>
> > ---
> > package/crosstool-ng/crosstool-ng.mk | 2 +-
> > .../crosstool-ng.config-eglibc | 73 ++++++++++++++-----
> > .../crosstool-ng.config-glibc | 74 +++++++++++++++-----
> > .../crosstool-ng.config-uClibc | 71 ++++++++++++++-----
> > 4 files changed, 165 insertions(+), 55 deletions(-)
>
> Thanks for doing this work. I think ct-ng now supports minimal
> defconfig files. Would it make sense to use that instead of
> full .config files in order to reduce the amount of churn when updating
> between ct-ng versions? Yann?
Indeed, but the defconfig support in crosstool-NG is not perfect yet, so
I think we should keep complete .config files for this release.
The problem with defconfigs in crosstool-NG is that there is no guarantee
about new symbols coming and going between versions, so this can result in
strange behaviors when a new version comes out, and a defconfig from a
previous version is used. Here's what may happen:
In version X, we use the latest stable 3.6 linux kernel, which is 3.6.2.
This is also the absolute latest version of the kernel. So we have this
symbol: LINUX_VER_3_6_2
The user did select this version. As 3.6.3 is the latest version, it is
the first item in the choice, so it does not appear in the defconfig,
being the default of the choice.
Now, version X+1 is out, and the stable 3.6 kernel is updated to 3.6.7,
so we get a new symbol, but the previous one no longer exists. Also,
kernel 3.7 is out, so the 3.6.7 is not the latest version available.
Now, the default symbol in the choice is not 3.6.x, but 3.7.x, which
is probably not what the user expected.
Thus, using the defconfig from the previous version will yield a
completely different .config.
This can be even more anoying with the gcc version, as we only have one
linaro release per gcc /generation/ (eg. 4.7). If the user did select
the latest linaro version (eg. 4.7) which was the default of the choice,
qnd the new release has a more recent mainstream version (eg. 4.8), but
no corresponding linaro version, then the gcc version will be bumnped
to 4.8, when the user did in fact want the linaro 4.7.
I have a pending change to fix this issue for all components, but it will
go in only for the next release, and that shall make using defconfigs from
a previous version relatively safe to use with a newer version.
Then, we can switch buildroot to using the ct-ng defconfigs, but until
then I think it is safer to use full .config files.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply
* [Buildroot] [PATCH 3/3] jquery-sparkline: bump to version 2.1
From: Gustavo Zacarias @ 2012-12-04 17:24 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354641847-5083-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/jquery-sparkline/jquery-sparkline.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/jquery-sparkline/jquery-sparkline.mk b/package/jquery-sparkline/jquery-sparkline.mk
index d79e762..76adad6 100644
--- a/package/jquery-sparkline/jquery-sparkline.mk
+++ b/package/jquery-sparkline/jquery-sparkline.mk
@@ -1,4 +1,4 @@
-JQUERY_SPARKLINE_VERSION = 1.6
+JQUERY_SPARKLINE_VERSION = 2.1
JQUERY_SPARKLINE_SITE = http://www.omnipotent.net/jquery.sparkline/$(JQUERY_SPARKLINE_VERSION)
JQUERY_SPARKLINE_SOURCE = jquery.sparkline.min.js
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 2/3] jquery-validation: bump to version 1.10.0
From: Gustavo Zacarias @ 2012-12-04 17:24 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354641847-5083-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/jquery-validation/jquery-validation.mk | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/package/jquery-validation/jquery-validation.mk b/package/jquery-validation/jquery-validation.mk
index 7d30270..746b534 100644
--- a/package/jquery-validation/jquery-validation.mk
+++ b/package/jquery-validation/jquery-validation.mk
@@ -1,13 +1,13 @@
-JQUERY_VALIDATION_VERSION = 1.9.0
+JQUERY_VALIDATION_VERSION = 1.10.0
JQUERY_VALIDATION_SITE = http://jquery.bassistance.de/validate
JQUERY_VALIDATION_SOURCE = jquery-validation-$(JQUERY_VALIDATION_VERSION).zip
define JQUERY_VALIDATION_EXTRACT_CMDS
- unzip -d $(BUILD_DIR) $(DL_DIR)/$(JQUERY_VALIDATION_SOURCE)
+ unzip -d $(@D) $(DL_DIR)/$(JQUERY_VALIDATION_SOURCE)
endef
define JQUERY_VALIDATION_INSTALL_TARGET_CMDS
- $(INSTALL) -m 0644 -D $(@D)/jquery.validate.min.js \
+ $(INSTALL) -m 0644 -D $(@D)/dist/jquery.validate.min.js \
$(TARGET_DIR)/var/www/jquery.validate.js
endef
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 1/3] jquery: bump to version 1.8.3
From: Gustavo Zacarias @ 2012-12-04 17:24 UTC (permalink / raw)
To: buildroot
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/jquery/jquery.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/jquery/jquery.mk b/package/jquery/jquery.mk
index fb3a1b4..871f7a0 100644
--- a/package/jquery/jquery.mk
+++ b/package/jquery/jquery.mk
@@ -1,4 +1,4 @@
-JQUERY_VERSION = 1.7.1
+JQUERY_VERSION = 1.8.3
JQUERY_SITE = http://code.jquery.com
JQUERY_SOURCE = jquery-$(JQUERY_VERSION).min.js
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] Qt library difference between E.so and just .so
From: Eric Bénard @ 2012-12-04 17:19 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CADKZYYJFAKFs5KmSbcU7o=wkWi1_wOVc6MhgZrOdALgr_iva+A@mail.gmail.com>
Hi Santhosh,
Le Sat, 1 Dec 2012 16:27:54 -0600,
Santhosh Ramani <srcoolz@gmail.com> a ?crit :
> I'm using buildroot 2012.08 to create rootfs for AM335x device and would
> like to compile in Qt libraries. I went through make menuconfig and I get
> libraries for Qt 4.8.2. However, when I try and run some of the same
> examples from the TI SDK it complains that it can't find *libQtGuiE.so.4.7.2
> *.
>
TI'SDK is generated using Yocto/OpenEmbedded which allows the creation
of both Qt Embedded _and_ Qt for Xorg librairies. In order to make
the difference between both libraries which may both be integrated in
the same SDK, the Qt Embedded libraries have the 'E' suffix and the
SDK provides the right config files to make qmake happy.
So if you generate a rootfs using buildroot, you need to compile the
examples with buildroot's toolchain to have a consistent library naming.
Best regards,
Eric
^ permalink raw reply
* [Buildroot] Qt library difference between E.so and just .so
From: Thiago A. Corrêa @ 2012-12-04 16:43 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CADKZYY+KTeh1qdbnzzj1th=n5TrwuzT+2RhvxzaK6-Wp8JN88w@mail.gmail.com>
Hi,
On Sat, Dec 1, 2012 at 11:44 PM, Santhosh Ramani <srcoolz@gmail.com> wrote:
> Hello Thiago,
>
> Thanks a lot for your response, I thought about it too. I actually changed
> the qk.mk to copy all the E version files, instead to see if the the example
> would run, and then I got this error:
>
> error while loading shared libraries: libgthread-2.0.so.0: cannot open
> shared object file: No such file or directory
>
> Any pointers on this one??
I guess you mean you changed it to copy the binaries from TI SDK?
Other system libraries won't match, such libgthread in this case.
> Also I'm thinking when I compile my Qt applications, I'm gonna use the new
> 4.8.2 library so that the applications don't use the TI version. Would this
> approach work?
>
Yeah, assuming TI didn't have to change Qt itself, a simple rebuild
using buildroot should work. Actually this has more chances of working
then transfering the binaries.
Kind Regards,
Thiago A. Correa
^ permalink raw reply
* [Buildroot] Qt library difference between E.so and just .so
From: Santhosh Ramani @ 2012-12-04 16:25 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CADKZYY+KTeh1qdbnzzj1th=n5TrwuzT+2RhvxzaK6-Wp8JN88w@mail.gmail.com>
Hello,
Can anyone please give me pointers on this one??
Thanks a bunch...
Regards
Santhosh
--
Greater the Difficulty....Sweeter is the Victory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121204/0a188f17/attachment.html>
^ permalink raw reply
* [Buildroot] Problem with NFS boot
From: Santhosh Ramani @ 2012-12-04 16:21 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50BDB55A.3070102@relinux.de>
Hello Stephen, Thomas,
Yes the solution mentioned by Thomas fixed it. Once I enabled devtmpfs...it
mounts it first and the udev starts. Thank you sooo very much.
[ 3.581359] VFS: Mounted root (nfs filesystem) on device 0:15.
[ 3.588256] devtmpfs: mounted
[ 3.591857] Freeing init memory: 228K
Starting logging: OK
Populating /dev using udev: [ 4.088989] udevd[712]: starting version 182
done
Initializing random number generator... done.
This is really helpful. thank you
Regards
Santhosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121204/507c01e9/attachment.html>
^ permalink raw reply
* [Buildroot] [PATCH 2/2] linux: bump 3.6.x stable version
From: Gustavo Zacarias @ 2012-12-04 14:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354631815-18202-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
linux/Config.in | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/linux/Config.in b/linux/Config.in
index f408ad5..ef3b2a1 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -21,7 +21,7 @@ choice
prompt "Kernel version"
config BR2_LINUX_KERNEL_3_6
- bool "3.6.8"
+ bool "3.6.9"
config BR2_LINUX_KERNEL_SAME_AS_HEADERS
bool "Same as toolchain kernel headers"
@@ -76,7 +76,7 @@ config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION
config BR2_LINUX_KERNEL_VERSION
string
- default "3.6.8" if BR2_LINUX_KERNEL_3_6
+ default "3.6.9" if BR2_LINUX_KERNEL_3_6
default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS
default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION
default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] kernel-headers: bump 3.{0, 4, 6}.x stable versions
From: Gustavo Zacarias @ 2012-12-04 14:36 UTC (permalink / raw)
To: buildroot
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
| 6 +++---
...all-fix-__packed-in-exported-kernel-head.patch} | 0
2 files changed, 3 insertions(+), 3 deletions(-)
rename toolchain/kernel-headers/{linux-3.0.53-headers_install-fix-__packed-in-exported-kernel-head.patch => linux-3.0.54-headers_install-fix-__packed-in-exported-kernel-head.patch} (100%)
--git a/toolchain/kernel-headers/Config.in b/toolchain/kernel-headers/Config.in
index 12b3956..6552c62 100644
--- a/toolchain/kernel-headers/Config.in
+++ b/toolchain/kernel-headers/Config.in
@@ -67,12 +67,12 @@ config BR2_DEFAULT_KERNEL_HEADERS
default "2.6.37.6" if BR2_KERNEL_HEADERS_2_6_37
default "2.6.38.8" if BR2_KERNEL_HEADERS_2_6_38
default "2.6.39.4" if BR2_KERNEL_HEADERS_2_6_39
- default "3.0.53" if BR2_KERNEL_HEADERS_3_0
+ default "3.0.54" if BR2_KERNEL_HEADERS_3_0
default "3.1.10" if BR2_KERNEL_HEADERS_3_1
default "3.2.34" if BR2_KERNEL_HEADERS_3_2
default "3.3.8" if BR2_KERNEL_HEADERS_3_3
- default "3.4.20" if BR2_KERNEL_HEADERS_3_4
+ default "3.4.21" if BR2_KERNEL_HEADERS_3_4
default "3.5.7" if BR2_KERNEL_HEADERS_3_5
- default "3.6.8" if BR2_KERNEL_HEADERS_3_6
+ default "3.6.9" if BR2_KERNEL_HEADERS_3_6
default "2.6" if BR2_KERNEL_HEADERS_SNAP
default $BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION
diff --git a/toolchain/kernel-headers/linux-3.0.53-headers_install-fix-__packed-in-exported-kernel-head.patch b/toolchain/kernel-headers/linux-3.0.54-headers_install-fix-__packed-in-exported-kernel-head.patch
similarity index 100%
rename from toolchain/kernel-headers/linux-3.0.53-headers_install-fix-__packed-in-exported-kernel-head.patch
rename to toolchain/kernel-headers/linux-3.0.54-headers_install-fix-__packed-in-exported-kernel-head.patch
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] xapp_init: bad substitution of mcookie path in startx
From: Thierry Bultel @ 2012-12-04 12:35 UTC (permalink / raw)
To: buildroot
Hi,
The generated "startx" has the host path for mcookie:
----------
esac
authdisplay=${display:-:0}
mcookie=`/nous/BASYSTEMES/Buildroot/output.imx6neon/host/usr/bin/mcookie`
if test x"$mcookie" = x; then
--------------------------
... and because of that, the X server does not start on target.
It should be "/usr/bin/mcookie"
Regards
Thierry
^ permalink raw reply
* [Buildroot] [PATCH v2] xtensa: add config option to enable longcalls option
From: Thomas Petazzoni @ 2012-12-04 9:17 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50BDB610.7080304@zankel.net>
On Tue, 04 Dec 2012 00:36:32 -0800, czankel wrote:
> > 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?
> The actual distance between call and destination is probably very
> dependent on compiler versions and compile options, etc., so might be
> hard to figure out what packages are affected. We might end up with a
> lot of packages with special Xtensa 'treatments'. Probably better to
> just have it always there.
Hum, right.
> It should actually be fine to always compile with the longcalls option,
> but I didn't just want to change it without having the option to keep
> the old behavior, hence the option.
I'd prefer to have it always enabled, I'd say. We try to not add
gazillions of very detailed architecture-specific options that are
hard to understand. Hardcore users will know how/where to remove this
option is they need, or they can even override it by passing a
-mno-longcalls option in BR2_TARGET_OPTIMIZATION.
What do you think?
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] package/crosstool-ng: update to 1.17.0
From: Thomas Petazzoni @ 2012-12-04 9:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354564065-24388-2-git-send-email-c.schoenert@t-online.de>
Dear Carsten Schoenert,
On Mon, 3 Dec 2012 20:47:45 +0100, Carsten Schoenert wrote:
> From: Carsten Schoenert <c.schoenert@t-online.de>
>
> Updating current crosstool-ng config files to 1.17.0
> crosstool-ng.config-eglibc
> crosstool-ng.config-glibc
> crosstool-ng.config-uClibc
>
> Signed-off-by: Carsten Schoenert <c.schoenert@t-online.de>
> ---
> package/crosstool-ng/crosstool-ng.mk | 2 +-
> .../crosstool-ng.config-eglibc | 73 ++++++++++++++-----
> .../crosstool-ng.config-glibc | 74 +++++++++++++++-----
> .../crosstool-ng.config-uClibc | 71 ++++++++++++++-----
> 4 files changed, 165 insertions(+), 55 deletions(-)
Thanks for doing this work. I think ct-ng now supports minimal
defconfig files. Would it make sense to use that instead of
full .config files in order to reduce the amount of churn when updating
between ct-ng versions? Yann?
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] How to handle modularity in buildroot?
From: Thomas Petazzoni @ 2012-12-04 9:10 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201212041249.14541.manningc2@actrix.gen.nz>
Dear Charles Manning,
On Tue, 4 Dec 2012 12:49:14 +1300, Charles Manning wrote:
> I am aware of this mechanism but I don't think it really gets me what I am
> after.
>
> I think that with defconfig, I would be able to make defconfig, then tweak the
> config to get a variant. But now if I change the base config, I then have to
> go through the process again for the variant.
>
> What I would like is the ability to have:
> * A base package
> * Production rootfs = base + production files.
> * Development rootfs = base + development files.
>
> Then a change to the base package automatically flows through the production +
> development rootfs.
>
> Is there a way to accomplish that?
First of all, thanks for your nice words about Buildroot, definitely
appreciated.
That said, if Buildroot is certainly simpler than OE, it also means
that Buildroot has a smaller feature set, and to some extent a bit less
flexibility.
What you can do to achieve what you want is use defconfig fragments.
For example:
* mysystem_base_defconfig.frag would contain:
BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_PATH="/home/thomas/x-tools/arm-br-arm926/usr/"
BR2_TOOLCHAIN_EXTERNAL_LARGEFILE=y
BR2_TOOLCHAIN_EXTERNAL_INET_IPV6=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_PACKAGE_BUSYBOX=y
* mysystem_prod_defconfig.frag would contain:
BR2_PACKAGE_APPLICATION1=y
BR2_PACKAGE_APPLICATION2=y
* mysystem_dev_defconfig.frag would contain:
BR2_PACKAGE_STRACE=y
BR2_PACKAGE_LTRACE=y
And then, when you want to do a production build:
make clean
cat mysystem_base_defconfig.frag mysystem_prod_defconfig.frag > configs/mysystem_prod_defconfig
make mysystem_prod_defconfig
make
And when you want to do a development build:
make clean
cat mysystem_base_defconfig.frag mysystem_dev_defconfig.frag > configs/mysystem_dev_defconfig
make mysystem_dev_defconfig
make
Basically, instead of having Buildroot providing this feature, we rely
on the simple manipulation of the configuration file.
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] How to handle modularity in buildroot?
From: Bjørn Forsman @ 2012-12-04 9:10 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201212041249.14541.manningc2@actrix.gen.nz>
On 4 December 2012 00:49, Charles Manning <cdhmanning@gmail.com> wrote:
[...]
> I think that with defconfig, I would be able to make defconfig, then tweak the
> config to get a variant. But now if I change the base config, I then have to
> go through the process again for the variant.
>
> What I would like is the ability to have:
> * A base package
> * Production rootfs = base + production files.
> * Development rootfs = base + development files.
>
> Then a change to the base package automatically flows through the production +
> development rootfs.
>
>
> Is there a way to accomplish that?
I don't know if it's possible to do that right now, but in principle
this is just a merge of a base config and an addon config. Say, if
there was an include directive in config files you'd be done. Maybe
you could try to create this merged config file by hand and see if
it's something that can be automated later?
1. make a (base) defconfig
2. make N new defconfigs with various extra options and call them addonN_config
3. remove the symbols found in the base config from all addonN_config files
Then, before the build, you do something like "cat base_config
addonN_config > config".
Best regards,
Bj?rn Forsman
^ permalink raw reply
* [Buildroot] Chances in skeleton don't appear in filesystem
From: Thomas Petazzoni @ 2012-12-04 9:03 UTC (permalink / raw)
To: buildroot
In-Reply-To: <slrnkbqn5h.1p8.narkewoody@zuhnb712.local.com>
Dear Woody Wu,
On Tue, 4 Dec 2012 02:16:11 +0000 (UTC), Woody Wu wrote:
> After some intial builds, I come up with idea to make chances in the
> default filesystem contents. Then I change the config to use customized
> filesystem skeleton (fs/skeleton) and changed the
> fs/skeleton/network/interfaces with expection that change could appear
> in the generated target file system. After another run of make,
> however, I did not see my chances by untar the rootfs.tar.bz2.
The skeleton is copied to output/target during the first make, and is
not copied again during subsequent invocations of make. If you want to
see your filesystem skeleton changes to be taken into account, you have
to do a "make clean; make" cycle.
> Then I
> tried to remove the output/target directory, this time I even got
> another error, 'output/target/etc/hosts: no such file or directory'.
Removing the output/target directory does not make sense and cannot
work. Buildroot does not know that it has been removed and therefore
does not retrigger the installation of all packages.
> What's the correct method to modify the defualt filesystem? Thanks.
Do use a custom skeleton, use a custom post-build script to copy/modify
files in output/target. See
http://elinux.org/images/2/2a/Using-buildroot-real-project.pdf starting
slide 22, and particularly slides 24 and 25.
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] How to handle modularity in buildroot?
From: Stephan Hoffmann @ 2012-12-04 9:01 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201212041249.14541.manningc2@actrix.gen.nz>
Am 04.12.2012 00:49, schrieb Charles Manning:
> On Tuesday 04 December 2012 12:17:13 ANDY KENNEDY wrote:
>
>>> Is there an easy way to have modular/hierarchical projects? For
>>> example I would like to have a base file system that holds common
>>> stuff but then have variants (eg. production vs development).
>>>
>>> In OE this is easy: just create a "basic system" package which is
>>> included in the recipes for each of the variants.
>>>
>>> How would this be tackled in buildroot?
>> I believe what you are looking for is 'make defconfig'. This will
>> provide a basic set of configuration options to get you going, then
>> you'll have to edit the things like processor family, processor type,
>> whether you want uClibc vs {e,}glibc, etc.
>>
>> The default config is usually okay for a first attempt, however, I like
>> to provide to others in my company a set of config files to choose from.
>> Those, I derive from just cranking through the menuconfig and save the
>> options off when I get done.
>>
>> If you are looking for more than this, there are a few other default
>> config files to attempt. To list those config files do a 'make help'.
>>
>> Hope this helps!
> Thanks Andy
>
> I am aware of this mechanism but I don't think it really gets me what I am
> after.
>
> I think that with defconfig, I would be able to make defconfig, then tweak the
> config to get a variant. But now if I change the base config, I then have to
> go through the process again for the variant.
>
> What I would like is the ability to have:
> * A base package
> * Production rootfs = base + production files.
> * Development rootfs = base + development files.
>
Hi Charles,
I think this could be best done with git. You could create a production
and a development branch both based on your common base. After updating
base both branches could either be rebased or the new base merged in.
> Then a change to the base package automatically flows through the production +
> development rootfs.
>
Well, not really automatically;-) To be honest, I am currently trying to
find an optimal git workflow for this.
Kind regards
Stephan
> Is there a way to accomplish that?
>
> Thanks
>
> Charles
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
--
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
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