* [Buildroot] [git commit] Allow to run severals post build scripts instead of only one
From: Peter Korsgaard @ 2012-11-17 16:23 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=dbf4978e6b1b24973cb7fbf9be636dda3ae67862
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Using severals post build scripts is usefull to share
script between severals boards/projects.
[Peter: fix trailing spaces in Config.in]
Signed-off-by: Philippe Reynes <philippe.reynes@sagemcom.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
Makefile | 5 +++--
system/Config.in | 11 ++++++-----
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index 3e7d520..7602499 100644
--- a/Makefile
+++ b/Makefile
@@ -470,8 +470,9 @@ endif
) > $(TARGET_DIR)/etc/os-release
ifneq ($(BR2_ROOTFS_POST_BUILD_SCRIPT),"")
- @$(call MESSAGE,"Executing post-build script")
- $(BR2_ROOTFS_POST_BUILD_SCRIPT) $(TARGET_DIR)
+ @$(call MESSAGE,"Executing post-build script\(s\)")
+ @$(foreach s, $(call qstrip,$(BR2_ROOTFS_POST_BUILD_SCRIPT)), \
+ $(s) $(TARGET_DIR)$(sep))
endif
ifeq ($(BR2_ENABLE_LOCALE_PURGE),y)
diff --git a/system/Config.in b/system/Config.in
index 10c9d9d..5823210 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -170,15 +170,16 @@ config BR2_ROOTFS_POST_BUILD_SCRIPT
string "Custom script to run before creating filesystem images"
default ""
help
- Specify a script to be run after the build has finished and before
- Buildroot starts packing the files into selected filesystem images.
+ Specify a space-separated list of scripts to be run after the build
+ has finished and before Buildroot starts packing the files into
+ selected filesystem images.
This gives users the oportunity to do board-specific cleanups,
add-ons and the like, so the generated files can be used directly
without further processing.
- The script is called with the target directory name as first and
- only argument. Make sure the exit code of that script is 0,
- otherwise make will stop after calling it.
+ These scripts are called with the target directory name as first and
+ only argument. Make sure the exit code of those scripts are 0,
+ otherwise make will stop after calling them.
endmenu
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] alsa-lib: bump to version 1.0.26
From: Peter Korsgaard @ 2012-11-17 16:13 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353155281-15122-1-git-send-email-gustavo@zacarias.com.ar>
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:
Gustavo> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Committed both, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit] alsa-utils: bump to version 1.0.26
From: Peter Korsgaard @ 2012-11-17 16:13 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=27abfbb4513bae931151778b5aa0783ca94ba0cc
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>
---
package/multimedia/alsa-utils/alsa-utils.mk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/multimedia/alsa-utils/alsa-utils.mk b/package/multimedia/alsa-utils/alsa-utils.mk
index 7043837..6228574 100644
--- a/package/multimedia/alsa-utils/alsa-utils.mk
+++ b/package/multimedia/alsa-utils/alsa-utils.mk
@@ -4,9 +4,9 @@
#
#############################################################
-ALSA_UTILS_VERSION = 1.0.25
+ALSA_UTILS_VERSION = 1.0.26
ALSA_UTILS_SOURCE = alsa-utils-$(ALSA_UTILS_VERSION).tar.bz2
-ALSA_UTILS_SITE = ftp://ftp.alsa-project.org/pub/utils
+ALSA_UTILS_SITE = http://alsa.cybermirror.org/utils
ALSA_UTILS_LICENSE = GPLv2
ALSA_UTILS_LICENSE_FILES = COPYING
ALSA_UTILS_INSTALL_STAGING = YES
^ permalink raw reply related
* [Buildroot] [git commit] alsa-lib: bump to version 1.0.26
From: Peter Korsgaard @ 2012-11-17 16:13 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=4f2e4f24d8a29c40519daa07f39e702a1d70fd4f
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>
---
package/alsa-lib/alsa-lib.mk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/alsa-lib/alsa-lib.mk b/package/alsa-lib/alsa-lib.mk
index 8ed1339..daa551d 100644
--- a/package/alsa-lib/alsa-lib.mk
+++ b/package/alsa-lib/alsa-lib.mk
@@ -4,9 +4,9 @@
#
#############################################################
-ALSA_LIB_VERSION = 1.0.25
+ALSA_LIB_VERSION = 1.0.26
ALSA_LIB_SOURCE = alsa-lib-$(ALSA_LIB_VERSION).tar.bz2
-ALSA_LIB_SITE = ftp://ftp.alsa-project.org/pub/lib
+ALSA_LIB_SITE = http://alsa.cybermirror.org/lib
ALSA_LIB_LICENSE = LGPLv2.1+
ALSA_LIB_LICENSE_FILES = COPYING
ALSA_LIB_INSTALL_STAGING = YES
^ permalink raw reply related
* [Buildroot] [PATCH] Warn the user about the usage of output/target as the root filesystem
From: Peter Korsgaard @ 2012-11-17 16:13 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353160334-30174-1-git-send-email-thomas.petazzoni@free-electrons.com>
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> A very common mistake done by our users is that they use
Thomas> output/target/ directory as their root filesystem. Even though this is
Thomas> loudly documented in our Buildroot manual, people don't read
Thomas> documentation, so it is not sufficient.
Committed with the typo fixed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit] Warn the user about the usage of output/target as the root filesystem
From: Peter Korsgaard @ 2012-11-17 16:12 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=9226a9907c4eb0fffab777f50e88b74aa14d1737
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
A very common mistake done by our users is that they use
output/target/ directory as their root filesystem. Even though this is
loudly documented in our Buildroot manual, people don't read
documentation, so it is not sufficient.
This patch adds a text file named
output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM which explains why
output/target isn't appropriate to use as the root filesystem. The
process is:
* At the beginning of the build, right after the skeleton has been
copied, support/misc/target-dir-warning.txt is copied to
output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM
* In the filesystem images creation code, this file is removed before
launching fakeroot, and restored right after that, so that this
file is not present in the generated root filesystem images.
Note that the file has not been added to the default skeleton for two
reasons:
* It would have annoying to have in our source tree a file named in
capital letters inside system/skeleton/
* The proposed way works even if the user uses a custom skeleton.
[Peter: fixed typo]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Juha Lumme <juha.lumme@gmail.com>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
Makefile | 5 +++++
fs/common.mk | 2 ++
support/misc/target-dir-warning.txt | 29 +++++++++++++++++++++++++++++
3 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index c526fe1..3e7d520 100644
--- a/Makefile
+++ b/Makefile
@@ -269,6 +269,10 @@ LEGAL_LICENSES_TXT=$(LEGAL_INFO_DIR)/licenses.txt
LEGAL_WARNINGS=$(LEGAL_INFO_DIR)/.warnings
LEGAL_REPORT=$(LEGAL_INFO_DIR)/README
+# Location of a file giving a big fat warning that output/target
+# should not be used as the root filesystem.
+TARGET_DIR_WARNING_FILE=$(TARGET_DIR)/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM
+
ifeq ($(BR2_CCACHE),y)
CCACHE:=$(HOST_DIR)/usr/bin/ccache
BUILDROOT_CACHE_DIR = $(call qstrip,$(BR2_CCACHE_DIR))
@@ -403,6 +407,7 @@ $(BUILD_DIR)/.root:
cp -fa $(TARGET_SKELETON)/* $(TARGET_DIR)/; \
fi; \
fi
+ cp support/misc/target-dir-warning.txt $(TARGET_DIR_WARNING_FILE)
-find $(TARGET_DIR) -type d -name CVS -print0 -o -name .svn -print0 | xargs -0 rm -rf
-find $(TARGET_DIR) -type f \( -name .empty -o -name '*~' \) -print0 | xargs -0 rm -rf
touch $@
diff --git a/fs/common.mk b/fs/common.mk
index 0f0eae9..b1512dd 100644
--- a/fs/common.mk
+++ b/fs/common.mk
@@ -45,6 +45,7 @@ $(BINARIES_DIR)/rootfs.$(1): $(ROOTFS_$(2)_DEPENDENCIES)
@$(call MESSAGE,"Generating root filesystem image rootfs.$(1)")
$(foreach hook,$(ROOTFS_$(2)_PRE_GEN_HOOKS),$(call $(hook))$(sep))
rm -f $(FAKEROOT_SCRIPT)
+ rm -f $(TARGET_DIR_WARNING_FILE)
echo "chown -R 0:0 $(TARGET_DIR)" >> $(FAKEROOT_SCRIPT)
ifneq ($(ROOTFS_DEVICE_TABLES),)
cat $(ROOTFS_DEVICE_TABLES) > $(FULL_DEVICE_TABLE)
@@ -57,6 +58,7 @@ endif
echo "$(ROOTFS_$(2)_CMD)" >> $(FAKEROOT_SCRIPT)
chmod a+x $(FAKEROOT_SCRIPT)
$(HOST_DIR)/usr/bin/fakeroot -- $(FAKEROOT_SCRIPT)
+ cp support/misc/target-dir-warning.txt $(TARGET_DIR_WARNING_FILE)
- at rm -f $(FAKEROOT_SCRIPT) $(FULL_DEVICE_TABLE)
$(foreach hook,$(ROOTFS_$(2)_POST_GEN_HOOKS),$(call $(hook))$(sep))
ifeq ($$(BR2_TARGET_ROOTFS_$(2)_GZIP),y)
diff --git a/support/misc/target-dir-warning.txt b/support/misc/target-dir-warning.txt
new file mode 100644
index 0000000..90f8841
--- /dev/null
+++ b/support/misc/target-dir-warning.txt
@@ -0,0 +1,29 @@
+Warning!
+========
+
+This directory does *not* contain the root filesystem that you can use
+on your embedded system. Since Buildroot does not run as root, it
+cannot create device files and set the permissions and ownership of
+files correctly in this directory to make it usable as a root
+filesystem.
+
+For that reason, do *not* use the contents of this directory to mount
+your root filesystem over NFS or copy the contents of this directory
+to a SD card or USB key, thinking it will work as the root filesystem
+for your embedded system. It will simply *not* work.
+
+Instead, if you need a usable root filesystem, please select one of
+the filesystem image formats available in the Buildroot configuration
+interface (make menuconfig or others) in the "Filesystem images"
+sub-menu. If you want to get a filesystem image that you can easily
+extract to your SD card or to some directory exposed through NFS,
+please use the "tar the root filesystem" option. It will generate a
+images/rootfs.tar image in your Buildroot output directory, which you
+can extract as root:
+
+ sudo tar -C /destination/of/extraction -xf images/rootfs.tar
+
+Those image files are created using the contents of the target/
+directory, but there is a post-processing step to create device files
+and set owernship/permissions properly even if Buildroot does not run
+as root.
^ permalink raw reply related
* [Buildroot] Solving the mesa3d build issue
From: Thomas Petazzoni @ 2012-11-17 14:03 UTC (permalink / raw)
To: buildroot
Hello,
The mesa3d build is currently broken because it generates during its
build process a bunch of C files from a XML description of the OpenGL
APIs. This generation process is done through Python scripts that
require the libxml2 Python bindings to be installed.
Unfortunately, those libxml2 Python bindings are part of the libxml2
source code itself, so we would have to enable host-python as a
dependency of host-libxml2 in order to get those Python bindings built
and installed. This means that all other users of host-libxml2 would
pay the price of building host-python even if they don't need it, which
is quite annoying.
We have several solutions to address this problem:
(1) The solution proposed by Will Wagner/Noel Vellemans at
http://lists.busybox.net/pipermail/buildroot/2012-November/061594.html
and
http://lists.busybox.net/pipermail/buildroot/2012-November/061595.html.
This solution consists in adding a BR2_PACKAGE_HOST_LIBXML2_PYTHON
hidden configuration symbol, that mesa3d selects. It sells the
host-libxml2 package that it should build the Python binding, and
therefore depend on host-python.
It is quite nice in the sense that it is simple and only builds
host-python as a dependency of host-libxml2 when needed. However,
it adds something entirely non-standard: a hidden kconfig option
that tunes the compilation of a host package. Do we want to do
this?
(2) Workaround the problem by adding the generated C files as patches
to the mesa3d package so that generating them at build time is not
needed. Unfortunately, those generated files are quite large, so
I'm not sure we want them as patches. And it also means they would
have to be updated whenever we bump the mesa3d version.
-rw-r--r-- 1 thomas thomas 181158 Nov 17 13:02 api_exec_es1.c
-rw-r--r-- 1 thomas thomas 94023 Nov 17 13:02 api_exec_es2.c
(3) Rewrite the small Python script that generates those C files so
that it uses the XML APIs available in the standard Python library
instead of the libxml2 XML APIs. This is not too complicated, but
doing it on the old 7.10.1 version we're using seems like a waste
of time (we'd better do it on a more recent version so that it
could maybe be upstreamed at some point). I've tried bumping
mesa3d. It is certainly doable, but requires the bumping of quite
a few other packages.
We really need to solve that problem, so I would be grateful if you
could comment on it. Peter?
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] Warn the user about the usage of output/target as the root filesystem
From: Richard Braun @ 2012-11-17 14:03 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353160334-30174-1-git-send-email-thomas.petazzoni@free-electrons.com>
On Sat, Nov 17, 2012 at 02:52:14PM +0100, Thomas Petazzoni wrote:
> +This directory does *not* contain the root filesystem that you can use
> +on your embedded system. Since Buildroot does not run as root, it
> +cannot create device files and set the permissions and ownership of
> +files correectly in this directory to make it usable as a root
> +filesystem.
Typo at "correectly".
--
Richard Braun
^ permalink raw reply
* [Buildroot] [PATCH] Warn the user about the usage of output/target as the root filesystem
From: Gustavo Zacarias @ 2012-11-17 13:59 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353160334-30174-1-git-send-email-thomas.petazzoni@free-electrons.com>
On 11/17/2012 10:52 AM, Thomas Petazzoni wrote:
> A very common mistake done by our users is that they use
> output/target/ directory as their root filesystem. Even though this is
> loudly documented in our Buildroot manual, people don't read
> documentation, so it is not sufficient.
>
> This patch adds a text file named
> output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM which explains why
> output/target isn't appropriate to use as the root filesystem. The
> process is:
>
> * At the beginning of the build, right after the skeleton has been
> copied, support/misc/target-dir-warning.txt is copied to
> output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM
>
> * In the filesystem images creation code, this file is removed before
> launching fakeroot, and restored right after that, so that this
> file is not present in the generated root filesystem images.
>
> Note that the file has not been added to the default skeleton for two
> reasons:
>
> * It would have annoying to have in our source tree a file named in
> capital letters inside system/skeleton/
>
> * The proposed way works even if the user uses a custom skeleton.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Juha Lumme <juha.lumme@gmail.com>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
^ permalink raw reply
* [Buildroot] [PATCH] Warn the user about the usage of output/target as the root filesystem
From: Thomas Petazzoni @ 2012-11-17 13:52 UTC (permalink / raw)
To: buildroot
A very common mistake done by our users is that they use
output/target/ directory as their root filesystem. Even though this is
loudly documented in our Buildroot manual, people don't read
documentation, so it is not sufficient.
This patch adds a text file named
output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM which explains why
output/target isn't appropriate to use as the root filesystem. The
process is:
* At the beginning of the build, right after the skeleton has been
copied, support/misc/target-dir-warning.txt is copied to
output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM
* In the filesystem images creation code, this file is removed before
launching fakeroot, and restored right after that, so that this
file is not present in the generated root filesystem images.
Note that the file has not been added to the default skeleton for two
reasons:
* It would have annoying to have in our source tree a file named in
capital letters inside system/skeleton/
* The proposed way works even if the user uses a custom skeleton.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Juha Lumme <juha.lumme@gmail.com>
---
Makefile | 5 +++++
fs/common.mk | 2 ++
support/misc/target-dir-warning.txt | 29 +++++++++++++++++++++++++++++
3 files changed, 36 insertions(+)
create mode 100644 support/misc/target-dir-warning.txt
diff --git a/Makefile b/Makefile
index c526fe1..3e7d520 100644
--- a/Makefile
+++ b/Makefile
@@ -269,6 +269,10 @@ LEGAL_LICENSES_TXT=$(LEGAL_INFO_DIR)/licenses.txt
LEGAL_WARNINGS=$(LEGAL_INFO_DIR)/.warnings
LEGAL_REPORT=$(LEGAL_INFO_DIR)/README
+# Location of a file giving a big fat warning that output/target
+# should not be used as the root filesystem.
+TARGET_DIR_WARNING_FILE=$(TARGET_DIR)/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM
+
ifeq ($(BR2_CCACHE),y)
CCACHE:=$(HOST_DIR)/usr/bin/ccache
BUILDROOT_CACHE_DIR = $(call qstrip,$(BR2_CCACHE_DIR))
@@ -403,6 +407,7 @@ $(BUILD_DIR)/.root:
cp -fa $(TARGET_SKELETON)/* $(TARGET_DIR)/; \
fi; \
fi
+ cp support/misc/target-dir-warning.txt $(TARGET_DIR_WARNING_FILE)
-find $(TARGET_DIR) -type d -name CVS -print0 -o -name .svn -print0 | xargs -0 rm -rf
-find $(TARGET_DIR) -type f \( -name .empty -o -name '*~' \) -print0 | xargs -0 rm -rf
touch $@
diff --git a/fs/common.mk b/fs/common.mk
index 0f0eae9..b1512dd 100644
--- a/fs/common.mk
+++ b/fs/common.mk
@@ -45,6 +45,7 @@ $(BINARIES_DIR)/rootfs.$(1): $(ROOTFS_$(2)_DEPENDENCIES)
@$(call MESSAGE,"Generating root filesystem image rootfs.$(1)")
$(foreach hook,$(ROOTFS_$(2)_PRE_GEN_HOOKS),$(call $(hook))$(sep))
rm -f $(FAKEROOT_SCRIPT)
+ rm -f $(TARGET_DIR_WARNING_FILE)
echo "chown -R 0:0 $(TARGET_DIR)" >> $(FAKEROOT_SCRIPT)
ifneq ($(ROOTFS_DEVICE_TABLES),)
cat $(ROOTFS_DEVICE_TABLES) > $(FULL_DEVICE_TABLE)
@@ -57,6 +58,7 @@ endif
echo "$(ROOTFS_$(2)_CMD)" >> $(FAKEROOT_SCRIPT)
chmod a+x $(FAKEROOT_SCRIPT)
$(HOST_DIR)/usr/bin/fakeroot -- $(FAKEROOT_SCRIPT)
+ cp support/misc/target-dir-warning.txt $(TARGET_DIR_WARNING_FILE)
- at rm -f $(FAKEROOT_SCRIPT) $(FULL_DEVICE_TABLE)
$(foreach hook,$(ROOTFS_$(2)_POST_GEN_HOOKS),$(call $(hook))$(sep))
ifeq ($$(BR2_TARGET_ROOTFS_$(2)_GZIP),y)
diff --git a/support/misc/target-dir-warning.txt b/support/misc/target-dir-warning.txt
new file mode 100644
index 0000000..b39b759
--- /dev/null
+++ b/support/misc/target-dir-warning.txt
@@ -0,0 +1,29 @@
+Warning!
+========
+
+This directory does *not* contain the root filesystem that you can use
+on your embedded system. Since Buildroot does not run as root, it
+cannot create device files and set the permissions and ownership of
+files correectly in this directory to make it usable as a root
+filesystem.
+
+For that reason, do *not* use the contents of this directory to mount
+your root filesystem over NFS or copy the contents of this directory
+to a SD card or USB key, thinking it will work as the root filesystem
+for your embedded system. It will simply *not* work.
+
+Instead, if you need a usable root filesystem, please select one of
+the filesystem image formats available in the Buildroot configuration
+interface (make menuconfig or others) in the "Filesystem images"
+sub-menu. If you want to get a filesystem image that you can easily
+extract to your SD card or to some directory exposed through NFS,
+please use the "tar the root filesystem" option. It will generate a
+images/rootfs.tar image in your Buildroot output directory, which you
+can extract as root:
+
+ sudo tar -C /destination/of/extraction -xf images/rootfs.tar
+
+Those image files are created using the contents of the target/
+directory, but there is a post-processing step to create device files
+and set owernship/permissions properly even if Buildroot does not run
+as root.
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] Built a file system, have a working kernel - how to login ?
From: Juha Lumme @ 2012-11-17 13:34 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CABYt4-ZRHdmbCAwtt8+swiwRHNwg=0_zEJxe7UnxetBgudXGKg@mail.gmail.com>
Hi Tomas, Shawn,
That was the problem! Now I get properly to the login prompt up! Thank you
guys so much! :)
Sigh, as always, I should have read the manual more carefully..
By the way, I also opened a question about this at Stack Overflow earlier,
so if you want earn some reputation in that forum, I'll pick your answer.
I'll answer it myself tomorrow, if you guys don't want/care about that
stuff.
http://stackoverflow.com/questions/13429068/buildroot-built-a-file-system-how-to-login-boot-hangs
Once again, thank you for your time!
Juha
On Sat, Nov 17, 2012 at 10:17 PM, Shawn Goff <shawnjgoff@gmail.com> wrote:
> > Please enable a tarball root filesystem image, and then extract is as
> > root on the partition of your memory card.
> >
>
> Since you said you're not yet familiar with Buildroot, I'll clarify
> that. Thomas is refering to the Buildroot option
> BR2_TARGET_ROOTFS_TAR. The resulting file is in output/images.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121117/1c748946/attachment.html>
^ permalink raw reply
* [Buildroot] Built a file system, have a working kernel - how to login ?
From: Shawn Goff @ 2012-11-17 13:17 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121117130703.03beb6e1@skate>
> Please enable a tarball root filesystem image, and then extract is as
> root on the partition of your memory card.
>
Since you said you're not yet familiar with Buildroot, I'll clarify
that. Thomas is refering to the Buildroot option
BR2_TARGET_ROOTFS_TAR. The resulting file is in output/images.
^ permalink raw reply
* [Buildroot] [PATCH 2/2] alsa-utils: bump to version 1.0.26
From: Gustavo Zacarias @ 2012-11-17 12:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353155281-15122-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/multimedia/alsa-utils/alsa-utils.mk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/multimedia/alsa-utils/alsa-utils.mk b/package/multimedia/alsa-utils/alsa-utils.mk
index 7043837..6228574 100644
--- a/package/multimedia/alsa-utils/alsa-utils.mk
+++ b/package/multimedia/alsa-utils/alsa-utils.mk
@@ -4,9 +4,9 @@
#
#############################################################
-ALSA_UTILS_VERSION = 1.0.25
+ALSA_UTILS_VERSION = 1.0.26
ALSA_UTILS_SOURCE = alsa-utils-$(ALSA_UTILS_VERSION).tar.bz2
-ALSA_UTILS_SITE = ftp://ftp.alsa-project.org/pub/utils
+ALSA_UTILS_SITE = http://alsa.cybermirror.org/utils
ALSA_UTILS_LICENSE = GPLv2
ALSA_UTILS_LICENSE_FILES = COPYING
ALSA_UTILS_INSTALL_STAGING = YES
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] alsa-lib: bump to version 1.0.26
From: Gustavo Zacarias @ 2012-11-17 12:28 UTC (permalink / raw)
To: buildroot
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/alsa-lib/alsa-lib.mk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/alsa-lib/alsa-lib.mk b/package/alsa-lib/alsa-lib.mk
index 8ed1339..daa551d 100644
--- a/package/alsa-lib/alsa-lib.mk
+++ b/package/alsa-lib/alsa-lib.mk
@@ -4,9 +4,9 @@
#
#############################################################
-ALSA_LIB_VERSION = 1.0.25
+ALSA_LIB_VERSION = 1.0.26
ALSA_LIB_SOURCE = alsa-lib-$(ALSA_LIB_VERSION).tar.bz2
-ALSA_LIB_SITE = ftp://ftp.alsa-project.org/pub/lib
+ALSA_LIB_SITE = http://alsa.cybermirror.org/lib
ALSA_LIB_LICENSE = LGPLv2.1+
ALSA_LIB_LICENSE_FILES = COPYING
ALSA_LIB_INSTALL_STAGING = YES
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] Built a file system, have a working kernel - how to login ?
From: Thomas Petazzoni @ 2012-11-17 12:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAF-Ht3zwxboYWZ6Q3ocMtFaAnQ9xEo+qfWfSsovdZuZa3sotkQ@mail.gmail.com>
Dear Juha Lumme,
On Sat, 17 Nov 2012 20:45:09 +0900, Juha Lumme wrote:
> The board boots from memory card currently, and I tarball the output/target
> directory and then decompress to the second partition on the memory card.
> This worked for a full 250MB debian file system, so I'm assuming it should
> work here as well..?
Aaargggh, no!
From the Buildroot manual:
target/ which contains almost the complete root filesystem for the
target: everything needed is present except the device files
in /dev/ (Buildroot can?t create them because Buildroot doesn?t run
as root and doesn?t want to run as root). Therefore, this directory
should not be used on your target.
Please enable a tarball root filesystem image, and then extract is as
root on the partition of your memory card.
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] [PATCH v4] Allow to run severals post build scripts instead of only one
From: Philippe Reynes @ 2012-11-17 12:01 UTC (permalink / raw)
To: buildroot
Using severals post build scripts is usefull to share
script between severals boards/projects.
Signed-off-by: Philippe Reynes <philippe.reynes@sagemcom.com>
---
v4: rebase patch with latest change
Makefile | 5 +++--
system/Config.in | 11 ++++++-----
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index c526fe1..03be469 100644
--- a/Makefile
+++ b/Makefile
@@ -465,8 +465,9 @@ endif
) > $(TARGET_DIR)/etc/os-release
ifneq ($(BR2_ROOTFS_POST_BUILD_SCRIPT),"")
- @$(call MESSAGE,"Executing post-build script")
- $(BR2_ROOTFS_POST_BUILD_SCRIPT) $(TARGET_DIR)
+ @$(call MESSAGE,"Executing post-build script\(s\)")
+ @$(foreach s, $(call qstrip,$(BR2_ROOTFS_POST_BUILD_SCRIPT)), \
+ $(s) $(TARGET_DIR)$(sep))
endif
ifeq ($(BR2_ENABLE_LOCALE_PURGE),y)
diff --git a/system/Config.in b/system/Config.in
index 10c9d9d..e448a40 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -170,15 +170,16 @@ config BR2_ROOTFS_POST_BUILD_SCRIPT
string "Custom script to run before creating filesystem images"
default ""
help
- Specify a script to be run after the build has finished and before
- Buildroot starts packing the files into selected filesystem images.
+ Specify a space-separated list of scripts to be run after the build
+ has finished and before Buildroot starts packing the files into
+ selected filesystem images.
This gives users the oportunity to do board-specific cleanups,
add-ons and the like, so the generated files can be used directly
without further processing.
- The script is called with the target directory name as first and
- only argument. Make sure the exit code of that script is 0,
- otherwise make will stop after calling it.
+ These scripts are called with the target directory name as first and
+ only argument. Make sure the exit code of those scripts are 0,
+ otherwise make will stop after calling them.
endmenu
--
1.7.1
#
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caract?re priv?. S'ils ne vous sont
pas destin?s, nous vous signalons qu'il est strictement interdit de les
divulguer, de les reproduire ou d'en utiliser de quelque mani?re que ce
soit le contenu. Si ce message vous a ?t? transmis par erreur, merci d'en
informer l'exp?diteur et de supprimer imm?diatement de votre syst?me
informatique ce courriel ainsi que tous les documents qui y sont attach?s."
******
" This e-mail and any attached documents may contain confidential or
proprietary information. If you are not the intended recipient, you are
notified that any dissemination, copying of this e-mail and any attachments
thereto or use of their contents by any means whatsoever is strictly
prohibited. If you have received this e-mail in error, please advise the
sender immediately and delete this e-mail and all attached documents
from your computer system."
#
^ permalink raw reply related
* [Buildroot] Built a file system, have a working kernel - how to login ?
From: Juha Lumme @ 2012-11-17 11:45 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121117123531.431cbd65@skate>
Hi Tomas,
The board boots from memory card currently, and I tarball the output/target
directory and then decompress to the second partition on the memory card.
This worked for a full 250MB debian file system, so I'm assuming it should
work here as well..?
Thanks,
Juha
On Nov 17, 2012 8:35 PM, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:
> Dear Juha Lumme,
>
> On Sat, 17 Nov 2012 20:07:28 +0900, Juha Lumme wrote:
>
> > My reference is Olinuxino maxi, made by Olimex. It's running Freescales
> > i.mx233.
>
> Ok.
>
> > Regarding the inittab and getty configuuration; Actually, that is a copy
> > paste error for some reason there is a hash in there. In the inittab,
> that
> > line is not commented out.
>
> Ok.
>
> > I didn't compile kernel with buildroot, since kernel requires couple
> > patches, and also the sources are downloaded from freescale, not
> kernel.org(
> >
> https://github.com/koliqi/imx23-olinuxino/blob/master/Building%20a%20kernel%20%20for%20the%20OLinuXino.md
> > ).
>
> Ok. It is most likely possible to get this kernel built with Buildroot,
> but let's compile it separately first and get it working this way.
>
> > I'm not that proficient with buildroot (or building kernels) that I know
> > how to enable buildroot to compile this "custom kernel".. Do you see this
> > making my life much more difficult if I compile kernel separately ?
>
> No.
>
> > I checked my kernel config, and it seems it has this flag enabled:
> > CONFIG_DEVTMPFS=y
> > However: # CONFIG_DEVTMPFS_MOUNT is not set
> >
> > In buildroot, I didn't change the /dev management, so it's currently set
> as
> > "static using device table". I guess there is a mismatch now..
>
> If you're using "static using device table", then CONFIG_DEVTMPFS=y is
> not needed, but it's harmless to have it.
>
> How do you install your root filesystem on the target?
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121117/d6144afc/attachment.html>
^ permalink raw reply
* [Buildroot] Built a file system, have a working kernel - how to login ?
From: Thomas Petazzoni @ 2012-11-17 11:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAF-Ht3xTA8gLLFS5j64LFSQ9_U5O7+42Uj0Yq4CMZWWZb3g3YA@mail.gmail.com>
Dear Juha Lumme,
On Sat, 17 Nov 2012 20:07:28 +0900, Juha Lumme wrote:
> My reference is Olinuxino maxi, made by Olimex. It's running Freescales
> i.mx233.
Ok.
> Regarding the inittab and getty configuuration; Actually, that is a copy
> paste error for some reason there is a hash in there. In the inittab, that
> line is not commented out.
Ok.
> I didn't compile kernel with buildroot, since kernel requires couple
> patches, and also the sources are downloaded from freescale, not kernel.org(
> https://github.com/koliqi/imx23-olinuxino/blob/master/Building%20a%20kernel%20%20for%20the%20OLinuXino.md
> ).
Ok. It is most likely possible to get this kernel built with Buildroot,
but let's compile it separately first and get it working this way.
> I'm not that proficient with buildroot (or building kernels) that I know
> how to enable buildroot to compile this "custom kernel".. Do you see this
> making my life much more difficult if I compile kernel separately ?
No.
> I checked my kernel config, and it seems it has this flag enabled:
> CONFIG_DEVTMPFS=y
> However: # CONFIG_DEVTMPFS_MOUNT is not set
>
> In buildroot, I didn't change the /dev management, so it's currently set as
> "static using device table". I guess there is a mismatch now..
If you're using "static using device table", then CONFIG_DEVTMPFS=y is
not needed, but it's harmless to have it.
How do you install your root filesystem on the target?
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] Built a file system, have a working kernel - how to login ?
From: Juha Lumme @ 2012-11-17 11:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121117111132.17a91542@skate>
Hi Tomas,
First, thanks for your reply, I really appreciate it!
My reference is Olinuxino maxi, made by Olimex. It's running Freescales
i.mx233.
Regarding the inittab and getty configuuration; Actually, that is a copy
paste error for some reason there is a hash in there. In the inittab, that
line is not commented out.
I didn't compile kernel with buildroot, since kernel requires couple
patches, and also the sources are downloaded from freescale, not kernel.org(
https://github.com/koliqi/imx23-olinuxino/blob/master/Building%20a%20kernel%20%20for%20the%20OLinuXino.md
).
I'm not that proficient with buildroot (or building kernels) that I know
how to enable buildroot to compile this "custom kernel".. Do you see this
making my life much more difficult if I compile kernel separately ?
I checked my kernel config, and it seems it has this flag enabled:
CONFIG_DEVTMPFS=y
However: # CONFIG_DEVTMPFS_MOUNT is not set
In buildroot, I didn't change the /dev management, so it's currently set as
"static using device table". I guess there is a mismatch now..
Thank you,
Juha
On Sat, Nov 17, 2012 at 7:11 PM, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:
> Dear Juha Lumme,
>
> On Sat, 17 Nov 2012 17:22:27 +0900, Juha Lumme wrote:
>
> > I'm new to buildroot, and actually also to creating linux systems. I
> really
> > need help understanding some basics of how a system bring up should
> happen..
> > I have been working on a custom system of mine, running currently on a
> > reference HW from Olimex.
> >
> > I have built a working kernel, and now I created a file system with
> > buildroot with all the settings default. Well, I did change the default
> > console to ttyAMA0, as that is passed to the kernel by the loader.
>
> Which /dev management method did you choose in the Buildroot
> configuration?
>
> > Now, the system boots up to the mounting filesystem, and then just hangs
> > there:
> > .....
> > [ 3.130000] VFS: Mounted root (ext3 filesystem) on device 179:2.
> > [ 3.140000] Freeing init memory: 144K
> > Starting logging: OK
> > Starting network...
> > ip: RTNETLINK answers: Operation not permitted
> > ip: SIOCSIFFLAGS: Permission denied
> >
> > (The whole boot log is here: http://paste.ubuntu.com/1364407/ )
> >
> > Can someone please educate me a bit what are the steps needed to get a
> > login prompt, and to be able to access the system ? I don't really
> > understand how the TTY links in /dev/ work, and how I need to tie them to
> > the kernel configuration..
> >
> > My understanding is that inittab is the file I should modify.. Contents
> of
> > that is:
>
> No, you shouldn't have to modify the inittab file.
>
> > # Startup the system
> > null::sysinit:/bin/mount -t proc proc /proc
> > null::sysinit:/bin/mount -o remount,rw / # REMOUNT_ROOTFS_RW
> > null::sysinit:/bin/mkdir -p /dev/pts
> > null::sysinit:/bin/mkdir -p /dev/shm
> > null::sysinit:/bin/mount -a
> > null::sysinit:/bin/hostname -F /etc/hostname
> > # now run any rc scripts
> > ::sysinit:/etc/init.d/rcS
> >
> > # Put a getty on the sttyAMA0::respawn:/sbin/getty -L ttyAMA0 115200
> vt100
> > # GENERIC_SERIAL
>
> If your inittab really looks like this, then there is no way it can
> work: the line starting getty is commented out.
>
> So:
>
> *) Do not modify the inittab
>
> *) Tell us what hardware you're using exactly, becausing depending on
> the hardware, the ttyXYZn to use is different.
>
> *) Tell us which /dev management style you've chosen. If you chose
> devtmpfs or mdev or udev, then make sure your kernel has
> CONFIG_DEVTMPFS + CONFIG_DEVTMPFS_MOUNT (Buildroot ensures that your
> kernel is built with those options if Buildroot is responsible for
> building your kernel, but if you build your kernel outside of
> Buildroot, it's your job).
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121117/f434fdd0/attachment.html>
^ permalink raw reply
* [Buildroot] [PATCH 1/2] Deprecate the support for the toolchain on target
From: Thomas Petazzoni @ 2012-11-17 11:06 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A76A1C.6030101@zacarias.com.ar>
On Sat, 17 Nov 2012 07:42:36 -0300, Gustavo Zacarias wrote:
> On 11/17/2012 05:21 AM, Peter Korsgaard wrote:
> > On the other hand, documentation on the target doesn't have the same
> > problems as toolchain, so if people do use it, I don't have a problem
> > keeping it.
> >
> > I've never personally used it though.
>
> On a related note there's no man-pages so the documentation is always
> kind of incomplete. There's no man package either, though busybox has one.
> And i don't recall anyone asking where man-pages is :)
> But it's a no brainer, it doesn't cause any significant overhead.
> Personally i've never used it either.
I also never use it, and I think that many packages do not install
their documentation, so it's most likely very incomplete.
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] [PATCH 1/2] Deprecate the support for the toolchain on target
From: Gustavo Zacarias @ 2012-11-17 10:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <87haoowsgi.fsf@dell.be.48ers.dk>
On 11/17/2012 05:21 AM, Peter Korsgaard wrote:
> On the other hand, documentation on the target doesn't have the same
> problems as toolchain, so if people do use it, I don't have a problem
> keeping it.
>
> I've never personally used it though.
On a related note there's no man-pages so the documentation is always
kind of incomplete. There's no man package either, though busybox has one.
And i don't recall anyone asking where man-pages is :)
But it's a no brainer, it doesn't cause any significant overhead.
Personally i've never used it either.
Regards.
^ permalink raw reply
* [Buildroot] [PATCH] libffi: Needs threads support in toolchain
From: Thomas Petazzoni @ 2012-11-17 10:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353140814-26164-1-git-send-email-maxime.ripard@free-electrons.com>
Dear Maxime Ripard,
On Sat, 17 Nov 2012 09:26:54 +0100, Maxime Ripard wrote:
> Fixes
> http://autobuild.buildroot.org/results/7ee57d01917ea72d1811469e482513dda2ceb1ea/build-end.log
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
As Peter said, your patch cannot work, as we have to fix all the
reverse dependencies. I'll try to cook a patch that removes the libffi
dependency on threads when threads are not available.
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] Built a file system, have a working kernel - how to login ?
From: Thomas Petazzoni @ 2012-11-17 10:11 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAF-Ht3yZfCDAMpPGJ7NFd_RQ0brOwxw3pSSoA3YFtzVf7kpf2g@mail.gmail.com>
Dear Juha Lumme,
On Sat, 17 Nov 2012 17:22:27 +0900, Juha Lumme wrote:
> I'm new to buildroot, and actually also to creating linux systems. I really
> need help understanding some basics of how a system bring up should happen..
> I have been working on a custom system of mine, running currently on a
> reference HW from Olimex.
>
> I have built a working kernel, and now I created a file system with
> buildroot with all the settings default. Well, I did change the default
> console to ttyAMA0, as that is passed to the kernel by the loader.
Which /dev management method did you choose in the Buildroot
configuration?
> Now, the system boots up to the mounting filesystem, and then just hangs
> there:
> .....
> [ 3.130000] VFS: Mounted root (ext3 filesystem) on device 179:2.
> [ 3.140000] Freeing init memory: 144K
> Starting logging: OK
> Starting network...
> ip: RTNETLINK answers: Operation not permitted
> ip: SIOCSIFFLAGS: Permission denied
>
> (The whole boot log is here: http://paste.ubuntu.com/1364407/ )
>
> Can someone please educate me a bit what are the steps needed to get a
> login prompt, and to be able to access the system ? I don't really
> understand how the TTY links in /dev/ work, and how I need to tie them to
> the kernel configuration..
>
> My understanding is that inittab is the file I should modify.. Contents of
> that is:
No, you shouldn't have to modify the inittab file.
> # Startup the system
> null::sysinit:/bin/mount -t proc proc /proc
> null::sysinit:/bin/mount -o remount,rw / # REMOUNT_ROOTFS_RW
> null::sysinit:/bin/mkdir -p /dev/pts
> null::sysinit:/bin/mkdir -p /dev/shm
> null::sysinit:/bin/mount -a
> null::sysinit:/bin/hostname -F /etc/hostname
> # now run any rc scripts
> ::sysinit:/etc/init.d/rcS
>
> # Put a getty on the sttyAMA0::respawn:/sbin/getty -L ttyAMA0 115200 vt100
> # GENERIC_SERIAL
If your inittab really looks like this, then there is no way it can
work: the line starting getty is commented out.
So:
*) Do not modify the inittab
*) Tell us what hardware you're using exactly, becausing depending on
the hardware, the ttyXYZn to use is different.
*) Tell us which /dev management style you've chosen. If you chose
devtmpfs or mdev or udev, then make sure your kernel has
CONFIG_DEVTMPFS + CONFIG_DEVTMPFS_MOUNT (Buildroot ensures that your
kernel is built with those options if Buildroot is responsible for
building your kernel, but if you build your kernel outside of
Buildroot, it's your job).
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] [PATCH] host-lua: fix bug #5354
From: Francois Perrad @ 2012-11-17 10:05 UTC (permalink / raw)
To: buildroot
see https://bugs.busybox.net/show_bug.cgi?id=5354
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
---
package/lua/lua.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/lua/lua.mk b/package/lua/lua.mk
index 9e0d387..3ce9867 100644
--- a/package/lua/lua.mk
+++ b/package/lua/lua.mk
@@ -24,7 +24,7 @@ endif
# We never want to have host-readline and host-ncurses as dependencies
# of host-lua.
HOST_LUA_DEPENDENCIES =
-HOST_LUA_CFLAGS = -Wall -fPIC -DLUA_USE_DLOPEN -DLUA_USE_POSIX
+HOST_LUA_CFLAGS = -Wall -fPIC -fno-stack-protector -DLUA_USE_DLOPEN -DLUA_USE_POSIX
HOST_LUA_MYLIBS = -ldl
define LUA_BUILD_CMDS
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] [git commit] lua-msgpack-native: fix fetch
From: Peter Korsgaard @ 2012-11-17 9:15 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=ee3a96137b6cbb8f970c540c61f75300a44ea803
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/lua-msgpack-native/lua-msgpack-native.mk | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/package/lua-msgpack-native/lua-msgpack-native.mk b/package/lua-msgpack-native/lua-msgpack-native.mk
index 5d8cd2d..97ce83c 100644
--- a/package/lua-msgpack-native/lua-msgpack-native.mk
+++ b/package/lua-msgpack-native/lua-msgpack-native.mk
@@ -3,9 +3,8 @@
# lua-msgpack-native
#
#############################################################
-LUA_MSGPACK_NATIVE_VERSION = 41cce91ab6
-LUA_MSGPACK_NATIVE_SITE = git://github.com/kengonakajima/lua-msgpack-native.git
-LUA_MSGPACK_NATIVE_METHOD = git
+LUA_MSGPACK_NATIVE_VERSION = g41cce91
+LUA_MSGPACK_NATIVE_SITE = http://github.com/kengonakajima/lua-msgpack-native/tarball/master
LUA_MSGPACK_NATIVE_DEPENDENCIES = lua
LUA_MSGPACK_NATIVE_LICENSE = Apache-2.0
LUA_MSGPACK_NATIVE_LICENSE_FILES = LICENSE.txt
^ permalink raw reply related
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