* [Buildroot] Using a precompiled busybox toolchain as an external toolchain
From: Willy Lambert @ 2012-12-30 12:56 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAKvQZ_2ZJ9GOV-B2Gi1zG-gjJiFVYHxpd4GzFCHCAg7ABAPFUA@mail.gmail.com>
2012/12/18 Willy Lambert <lambert.willy@gmail.com>:
> 2012/12/18 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
>> Dear Willy Lambert,
>>
>> On Tue, 18 Dec 2012 16:19:47 +0100, Willy Lambert wrote:
>>
>>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah. To be honest an entry
>>> in the manual to state this would be nice.
>>
>> Indeed. Feel free to submit a patch for the manual :-)
>>
>
> yes, but how ? Should I edit html files by and in the docs/manual folder ?
> I'm not at ease with git, so I will see during hollidays if I can do
> something with it.
>
>>> thanks, should I understand that I can't publish the buildroot
>>> toolchain on another PC without installing it at the __same__ place ?
>>
may I bump this, how should I edit documentation ?
I succeeded in creating the toolchain in "MY_TOOLCAHIN_PATH", but :
_ if I do a make clean it disapear, so I suppose I have to change
BR2_HOST_DIR back the default value after having creating the
toolchain ?
_ what's happening if I create several toolchain for several arch in
the same "MY_TOOLCHAIN_PATH ? does they override or do they install
nicely both in the same dir ?
_ what is the path I have to give to buildroot ? "MY_TOOLCHAIN_PATH'
or something like "MY_TOOLCHAIN_PATH'/usr/...
>> Your understanding is correct. Making the toolchain relocatable is part
>> of our TODO-list, though.
>>
>
> Ok thanks
>
>> 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] [autobuild.buildroot.net] Build results for 2012-12-29
From: Peter Korsgaard @ 2012-12-30 13:08 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50E02D8F.7020504@zacarias.com.ar>
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:
Hi,
Gustavo> On 12/30/2012 07:02 AM, Peter Korsgaard wrote:
>> These two looks related to your recent gnutls version bump. Care to have
>> a look?
Gustavo> Running a failing config now, i don't think i'll hit it
Gustavo> barebones though since they look like a pretty regular config.
Gustavo> Probably have to debootstrap.
Thanks.
>> This is probably also related to it, but perhaps that gets fixed by
>> Thomas' e17 update.
Gustavo> Seems unlikely from looking at the source of ecore.
Gustavo> Since people have been using and accustomed to gnutls-2.x
Gustavo> which required libgcrypt they've been including it blindly.
Gustavo> I'll test to see if it really requires libgcrypt (like
Gustavo> ntfs-3g) or it's just probably following old gnutls
Gustavo> instructions and fix accordingly.
Great, thanks.
>> Did you have a look at the host-gawk issue?
Gustavo> Yes, it seems peko-specific so my hunch says it's a distro
Gustavo> toolchain thing. I've asked Thomas and it seems it's runnig
Gustavo> gcc 4.3.2. Looks like the new gawk DFA is triggering a bug or
Gustavo> using a newer feature that it shouldn't. Couldn't reproduce
Gustavo> yet, so an old gentoo stage or debootstrap might help me. So
Gustavo> also looking into it. A puny dual-core won't help me with
Gustavo> getting these things solved quickly though, except libecore :)
You can always request a login to the GCC compile farm if you want to
check on gcc14:
http://gcc.gnu.org/wiki/CompileFarm
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] Using a precompiled busybox toolchain as an external toolchain
From: Samuel Martin @ 2012-12-30 13:53 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAKvQZ_1hK1dXwVs5W5XpuZY=O6AZj-Y8XtCHirW+wyXQ4Fwx8g@mail.gmail.com>
Hi Willy, all,
Apologize for the late answer.
2012/12/30 Willy Lambert <lambert.willy@gmail.com>:
> 2012/12/18 Willy Lambert <lambert.willy@gmail.com>:
>> 2012/12/18 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
>>> Dear Willy Lambert,
>>>
>>> On Tue, 18 Dec 2012 16:19:47 +0100, Willy Lambert wrote:
>>>
>>>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah. To be honest an entry
>>>> in the manual to state this would be nice.
>>>
>>> Indeed. Feel free to submit a patch for the manual :-)
>>>
>>
>> yes, but how ? Should I edit html files by and in the docs/manual folder ?
Please edit the manual from docs/manual, this is the reference now.
See http://buildroot.org/downloads/manual/manual.html#_the_documentation
>> I'm not at ease with git, so I will see during hollidays if I can do
>> something with it.
Well, from my experience, playing with git is the best way to learn it! :P
BTW, there is a lot of doc and so on around the web, e.g.:
- http://try.github.com/levels/1/challenges/1
- http://git-scm.com/documentation
- ...
Concerning patch posting to Buildroot, the online manual gathers the
few useful things, see:
http://buildroot.org/downloads/manual/manual.html#submitting-patches
Lastly, if you sneak around on the Buildroot IRC channel, there will
most likely be
someone who will be able to help you with git. ;-)
>>
>>>> thanks, should I understand that I can't publish the buildroot
>>>> toolchain on another PC without installing it at the __same__ place ?
>>>
>
> may I bump this, how should I edit documentation ?
I guess you're using a git view of BR, so please pull it and rebuild the manual:
make manual-clean manual
Few things related to this have been merged yesterday thanks to Thomas! ;-)
>
> I succeeded in creating the toolchain in "MY_TOOLCAHIN_PATH", but :
> _ if I do a make clean it disapear, so I suppose I have to change
> BR2_HOST_DIR back the default value after having creating the
> toolchain ?
> _ what's happening if I create several toolchain for several arch in
> the same "MY_TOOLCHAIN_PATH ? does they override or do they install
> nicely both in the same dir ?
> _ what is the path I have to give to buildroot ? "MY_TOOLCHAIN_PATH'
> or something like "MY_TOOLCHAIN_PATH'/usr/...
In the updated manual (the one you should have built; unfortunately
not online until the next release),
check the paragraph entitled "External toolchain backend" in the 3.1.1 section.
Basically, if you want to build a toolchain with BR, but avoid de
remove and rebuild it after each "make clean",
you should build the toolchain first with Buildroot in some place (see
http://buildroot.org/downloads/manual/manual.html#_building_out_of_tree),
then use it as an external toolchain in another configuration, in
another build directory
(see http://buildroot.org/downloads/manual/manual.html#external-toolchain).
To do so (after backuping your current BR config):
1) run 'make menuconfig O=/path/to/somewhere',
2) set the same toolchain configuration as your working configuration,
and disable everything from the following menus:
- System configuration
- Package Selection for the target
- Filesystem images
- Bootloaders
- Kernel
3) run 'make O=/path/to/somewhere'.
This should build the toolchain and pretty much nothing else.
4) run 'make menuconfig' and update the toolchain configuration:
Toolchain type (External toolchain)
Toolchain (Custom toolchain)
Toolchain origin (Pre-installed toolchain)
(/path/to/somewhere/host/usr) Toolchain path
Regards,
--
Samuel
^ permalink raw reply
* [Buildroot] [git commit] target: add option to set the root password
From: Peter Korsgaard @ 2012-12-30 17:00 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=a45871bfc6a3f800548954dd364b5f53e81804ab
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Add an option in the menuconfig to specify a root password.
If set to empty, no root password is created; otherwise, the password is
encrypted using MD5 (MD5 is not the default for crypt(3), DES-56 is, but
MD5 is widely available, not-so-strong, but not-so-weak either).
Add a check for 'mkpasswd' as a new dependency.
[Peter: fix typo/capitilization and simplify logic]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
support/dependencies/dependencies.sh | 9 +++++++++
system/Config.in | 21 +++++++++++++++++++++
system/system.mk | 9 +++++++++
3 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/support/dependencies/dependencies.sh b/support/dependencies/dependencies.sh
index 7a02512..eb5a481 100755
--- a/support/dependencies/dependencies.sh
+++ b/support/dependencies/dependencies.sh
@@ -158,6 +158,7 @@ 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 javac jar; do
if ! which $prog > /dev/null ; then
@@ -166,3 +167,11 @@ if grep -q ^BR2_PACKAGE_CLASSPATH=y $CONFIG_FILE ; then
fi
done
fi
+
+if grep -E '^BR2_TARGET_GENERIC_ROOT_PASSWD=".+"$' $CONFIG_FILE > /dev/null 2>&1; then
+ if ! which mkpasswd > /dev/null 2>&1; then
+ /bin/echo -e "\nYou need the 'mkpasswd' utility to set the root password\n"
+ /bin/echo -e "(in Debian/ubuntu, 'mkpasswd' provided by the whois package)\n"
+ exit 1
+ fi
+fi
diff --git a/system/Config.in b/system/Config.in
index a557ea0..f1c260a 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -12,6 +12,27 @@ config BR2_TARGET_GENERIC_ISSUE
help
Select system banner (/etc/issue) to be displayed at login.
+config BR2_TARGET_GENERIC_ROOT_PASSWD
+ string "Root password"
+ default ""
+ help
+ Set the initial root password (in clear). It will be md5-encrypted.
+
+ If set to empty (the default), then no root password will be set,
+ and root will need no password to log in.
+
+ WARNING! WARNING!
+ Although pretty strong, MD5 is now an old hash function, and
+ suffers from some weaknesses, which makes it susceptible to attacks.
+ It is showing its age, so this root password should not be trusted
+ to properly secure any product that can be shipped to the wide,
+ hostile world.
+
+ WARNING! WARNING!
+ The password appears in clear in the .config file, and may appear
+ in the build log! Avoid using a valuable password if either the
+ .config file or the build log may be distributed!
+
choice
prompt "/dev management"
default BR2_ROOTFS_DEVICE_CREATION_STATIC
diff --git a/system/system.mk b/system/system.mk
index 353d0ba..7536ce6 100644
--- a/system/system.mk
+++ b/system/system.mk
@@ -1,5 +1,9 @@
TARGET_GENERIC_HOSTNAME:=$(call qstrip,$(BR2_TARGET_GENERIC_HOSTNAME))
TARGET_GENERIC_ISSUE:=$(call qstrip,$(BR2_TARGET_GENERIC_ISSUE))
+TARGET_GENERIC_ROOT_PASSWD:=$(call qstrip,$(BR2_TARGET_GENERIC_ROOT_PASSWD))
+ifneq ($(TARGET_GENERIC_ROOT_PASSWD),)
+TARGET_GENERIC_ROOT_PASSWD_HASH=$(shell mkpasswd -m md5 "$(TARGET_GENERIC_ROOT_PASSWD)")
+endif
TARGET_GENERIC_GETTY:=$(call qstrip,$(BR2_TARGET_GENERIC_GETTY_PORT))
TARGET_GENERIC_GETTY_BAUDRATE:=$(call qstrip,$(BR2_TARGET_GENERIC_GETTY_BAUDRATE))
TARGET_GENERIC_GETTY_TERM:=$(call qstrip,$(BR2_TARGET_GENERIC_GETTY_TERM))
@@ -14,6 +18,9 @@ target-generic-issue:
mkdir -p $(TARGET_DIR)/etc
echo "$(TARGET_GENERIC_ISSUE)" > $(TARGET_DIR)/etc/issue
+target-root-passwd:
+ $(SED) 's,^root:[^:]*:,root:$(TARGET_GENERIC_ROOT_PASSWD_HASH):,' $(TARGET_DIR)/etc/shadow
+
target-generic-getty-busybox:
$(SED) '/# GENERIC_SERIAL$$/s~^.*#~$(TARGET_GENERIC_GETTY)::respawn:/sbin/getty -L $(TARGET_GENERIC_GETTY) $(TARGET_GENERIC_GETTY_BAUDRATE) $(TARGET_GENERIC_GETTY_TERM) #~' \
$(TARGET_DIR)/etc/inittab
@@ -40,6 +47,8 @@ ifneq ($(TARGET_GENERIC_ISSUE),)
TARGETS += target-generic-issue
endif
+TARGETS += target-root-passwd
+
ifeq ($(BR2_ROOTFS_SKELETON_DEFAULT),y)
ifeq ($(BR2_PACKAGE_SYSVINIT),y)
TARGETS += target-generic-getty-sysvinit
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] target: add option to set the root password
From: Peter Korsgaard @ 2012-12-30 17:01 UTC (permalink / raw)
To: buildroot
In-Reply-To: <0e6cac687daa80382f614d38c6394947eab5d892.1356739565.git.yann.morin.1998@free.fr>
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
Yann> Add an option in the menuconfig to specify a root password.
Yann> If set to empty, no root password is created; otherwise, the password is
Yann> encrypted using MD5 (MD5 is not the default for crypt(3), DES-56 is, but
Yann> MD5 is widely available, not-so-strong, but not-so-weak either).
Yann> Add a check for 'mkpasswd' as a new dependency.
Yann> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Yann> Cc: Arnout Vandecappelle <arnout@mind.be>
Yann> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Yann> +config BR2_TARGET_GENERIC_ROOT_PASSWD
Yann> + string "root password"
The rest of the options here are capitilized, so I've done that as well
here.
Yann> + default ""
Yann> + help
Yann> + Set the initial root password (in clear). It will be md5-encrypted.
Yann> +
Yann> + If set to empty (the default), then no root password will be set,
Yann> + and root will need no password to log in.
Yann> +
Yann> + WARNING! WARNING!
Yann> + Although pretty strong, MD5 is now an old hash function, and
Yann> + suffers from som weaknesses, which makes it susceptible to attacks.
s/som/some/
Yann> +target-no-root-passwd:
Yann> + $(SED) "s/^root:[^:]*:/root::/" $(TARGET_DIR)/etc/shadow
Yann> +
Yann> +target-root-passwd:
Yann> + root_passwd="$$( mkpasswd -m md5 "$(TARGET_GENERIC_ROOT_PASSWD)" )"; \
Yann> + $(SED) "s,^root::,root:$${root_passwd}:," $(TARGET_DIR)/etc/shadow
Yann> +
The 2nd sed only applies if the root passwd isn't set (E.G. running make
menuconfig and changing password + make doesn't work), so I've
simplified the two cases together to simply replace root:[^:]*: with
root:$(TARGET_GENERIC_ROOT_PASSWD_HASH): which is either the empty
string or the mkpasswd -m md5 output.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [PATCH 2/2] target: add different methods to encode the root password
From: Peter Korsgaard @ 2012-12-30 17:02 UTC (permalink / raw)
To: buildroot
In-Reply-To: <9a13fa348b5d4f9039c48e2ec539256d567d7483.1356739565.git.yann.morin.1998@free.fr>
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
Yann> The password can be encoded in different ways (from the weakest
Yann> to the strongest): des, md5, sha-256, sha-512
Yann> Add a choice entry to select the method, defaulting to 'md5'.
Care to respin this on top of mainline (E.G. after I changed the logic)?
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [PATCH 2/2] target: add different methods to encode the root password
From: Yann E. MORIN @ 2012-12-30 17:15 UTC (permalink / raw)
To: buildroot
In-Reply-To: <87623jtqv5.fsf@dell.be.48ers.dk>
Peter, All,
On Sunday 30 December 2012 Peter Korsgaard wrote:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
>
> Yann> The password can be encoded in different ways (from the weakest
> Yann> to the strongest): des, md5, sha-256, sha-512
>
> Yann> Add a choice entry to select the method, defaulting to 'md5'.
>
> Care to respin this on top of mainline (E.G. after I changed the logic)?
Yes, I'll do.
Thanks!
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] Bootloader
From: Willy Lambert @ 2012-12-30 17:18 UTC (permalink / raw)
To: buildroot
Hi all,
I'm having very hard time for some weeks now with action to do after
the "make" to play with generated stuff. The better hints I found on
the web was this :
http://osmz.mrl.cz/buildroot.html
I managed to create a "partitionned" image file but it fails on my
machine with grub install.
It makes me wonder what is the default way to go with bootloaders with
buildroot generated stuff.
I tried several options but none worked, I'm missing some
documentation to start with anything.
The one I know the most is grub, but I need a "grub-install" phasis
but no "host-tool" seems to be provided.
Is there any documentation on how to use bootloaders with buildroot ?
^ permalink raw reply
* [Buildroot] [PATCH] matchbox-lib: fix license info
From: Samuel Martin @ 2012-12-30 17:29 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHXCMM+kv+cFbgV3rDTdFz7h=R2pyB3XEAjHD=JKJs7TSpqRDQ@mail.gmail.com>
pong?
--
Samuel
^ permalink raw reply
* [Buildroot] [RFC] Allow packages to create users
From: Yann E. MORIN @ 2012-12-30 17:44 UTC (permalink / raw)
To: buildroot
Hello All!
Recently, I've had the need for a package to create a user to
run its daemon as:
http://lists.busybox.net/pipermail/buildroot/2012-December/064044.html
The solution was ugly and very specific to this package, so it was
(rightfully!) refused, until there is a generic way for packages to
create users.
I now have a prototype that is working in simple cases:
https://gitorious.org/buildroot/buildroot/commits/yem-package-create-user
(The commit titled 'package/foo: new package to test adding users' is a
dummy, temporary commit, it will be removed before a pull-request is made).
The documentation for this new feature is available at:
http://ymorin.is-a-geek.org/download/tmp/br/manual/manual.html#generic-package-reference
The new variable is FOO_USERS, with its syntax defined here:
http://ymorin.is-a-geek.org/download/tmp/br/manual/manual.html#makeuser-syntax
I'd appreciate comments, especially on the syntax.
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] Bootloader
From: Richard Braun @ 2012-12-30 17:50 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAKvQZ_069zGz=-uY_uTP90ycd8+S9LBXiR_RuOUYrtZW4g3WEw@mail.gmail.com>
On Sun, Dec 30, 2012 at 06:18:39PM +0100, Willy Lambert wrote:
> The one I know the most is grub, but I need a "grub-install" phasis
> but no "host-tool" seems to be provided.
This problem is specific to the x86 architecture. I've posted a way to
work around this issue [1] some time ago, along with a template script
you can adjust to your needs [2]. If your host is an x86_64 machine, be
sure to install 32-bit versions of your main libraries (e.g. libc6-i386
on Debian Squeeze). Hope it helps.
--
Richard Braun
[1] http://lists.busybox.net/pipermail/buildroot/2012-August/057536.html
[2] http://lists.busybox.net/pipermail/buildroot/2012-August/057538.html
^ permalink raw reply
* [Buildroot] [pull request v5] Pull request for branch yem-root-passwd
From: Yann E. MORIN @ 2012-12-30 18:08 UTC (permalink / raw)
To: buildroot
Hello Peter, All,
As requested, here's the re-spin of the second-part of the 'root-paswd'
series.
Note however these few changes since the previous iteration:
Changes v4 -> v5:
- drop patch #1, applied upstream (Peter)
- make the password-encoding scheme generic (ie. not root-speific)
- rebase on-top current master
The following changes since commit a45871bfc6a3f800548954dd364b5f53e81804ab:
target: add option to set the root password (2012-12-30 18:00:16 +0100)
are available in the git repository at:
git://gitorious.org/buildroot/buildroot.git yem-root-passwd
Yann E. MORIN (1):
target: add different methods to encode passwords
system/Config.in | 62 +++++++++++++++++++++++++++++++++++++++++++++++++----
system/system.mk | 3 +-
2 files changed, 59 insertions(+), 6 deletions(-)
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 1/1] target: add different methods to encode passwords
From: Yann E. MORIN @ 2012-12-30 18:08 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1356890711.git.yann.morin.1998@free.fr>
Passwords can be encoded in different ways (from the weakest
to the strongest): des, md5, sha-256, sha-512
Add a choice entry to select the method, defaulting to 'md5'.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
Previously, this was specific to encode the root password.
I have made it generic (ie. not root-specific), in case
buildroot needs to encode other passwords in the future
(eg. when packages can create users, for which I've just
sent an RFC)
---
system/Config.in | 62 +++++++++++++++++++++++++++++++++++++++++++++++++----
system/system.mk | 3 +-
2 files changed, 59 insertions(+), 6 deletions(-)
diff --git a/system/Config.in b/system/Config.in
index f1c260a..0978be7 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -12,6 +12,60 @@ config BR2_TARGET_GENERIC_ISSUE
help
Select system banner (/etc/issue) to be displayed at login.
+choice
+ bool "Passwords encoding"
+ default BR2_TARGET_GENERIC_PASSWD_MD5
+ help
+ Choose the password encoding scheme to use when Buildroot
+ needs to encode a password (eg. the root password, below).
+
+ Note: this is used at build-time, and *not* at runtime.
+
+config BR2_TARGET_GENERIC_PASSWD_DES
+ bool "des"
+ help
+ Use standard 56-bit DES-based crypt(3) to encode passwords.
+
+ Old, wildly available, but also the weakest, very susceptible to
+ brute-force attacks.
+
+config BR2_TARGET_GENERIC_PASSWD_MD5
+ bool "md5"
+ help
+ Use MD5 to encode passwords.
+
+ The default. Wildly available, and pretty good.
+ Although pretty strong, MD5 is now an old hash function, and
+ suffers from some weaknesses, which makes it susceptible to
+ brute-force attacks.
+
+config BR2_TARGET_GENERIC_PASSWD_SHA256
+ bool "sha-256"
+ help
+ Use SHA256 to encode passwords.
+
+ Very strong, but not ubiquitous, although available in glibc
+ for some time now. Choose only if you are sure your C library
+ understands SHA256 passwords.
+
+config BR2_TARGET_GENERIC_PASSWD_SHA512
+ bool "sha-512"
+ help
+ Use SHA512 to encode passwords.
+
+ Extremely strong, but not ubiquitous, although available in glibc
+ for some time now. Choose only if you are sure your C library
+ understands SHA512 passwords.
+
+endchoice # Passwd encoding
+
+config BR2_TARGET_GENERIC_PASSWD_METHOD
+ string
+ default "des" if BR2_TARGET_GENERIC_PASSWD_DES
+ default "md5" if BR2_TARGET_GENERIC_PASSWD_MD5
+ default "sha-256" if BR2_TARGET_GENERIC_PASSWD_SHA256
+ default "sha-512" if BR2_TARGET_GENERIC_PASSWD_SHA512
+
config BR2_TARGET_GENERIC_ROOT_PASSWD
string "Root password"
default ""
@@ -22,11 +76,9 @@ config BR2_TARGET_GENERIC_ROOT_PASSWD
and root will need no password to log in.
WARNING! WARNING!
- Although pretty strong, MD5 is now an old hash function, and
- suffers from some weaknesses, which makes it susceptible to attacks.
- It is showing its age, so this root password should not be trusted
- to properly secure any product that can be shipped to the wide,
- hostile world.
+ You should not trust this password to properly secure any product that
+ can be shipped to the wide, hostile world, depending on the type of
+ password encoding you choose above (especially if you choose md5 or des).
WARNING! WARNING!
The password appears in clear in the .config file, and may appear
diff --git a/system/system.mk b/system/system.mk
index 7536ce6..e964e46 100644
--- a/system/system.mk
+++ b/system/system.mk
@@ -1,8 +1,9 @@
TARGET_GENERIC_HOSTNAME:=$(call qstrip,$(BR2_TARGET_GENERIC_HOSTNAME))
TARGET_GENERIC_ISSUE:=$(call qstrip,$(BR2_TARGET_GENERIC_ISSUE))
TARGET_GENERIC_ROOT_PASSWD:=$(call qstrip,$(BR2_TARGET_GENERIC_ROOT_PASSWD))
+TARGET_GENERIC_PASSWD_METHOD:=$(call qstrip,$(BR2_TARGET_GENERIC_PASSWD_METHOD))
ifneq ($(TARGET_GENERIC_ROOT_PASSWD),)
-TARGET_GENERIC_ROOT_PASSWD_HASH=$(shell mkpasswd -m md5 "$(TARGET_GENERIC_ROOT_PASSWD)")
+TARGET_GENERIC_ROOT_PASSWD_HASH=$(shell mkpasswd -m "$(TARGET_GENERIC_PASSWD_METHOD)" "$(TARGET_GENERIC_ROOT_PASSWD)")
endif
TARGET_GENERIC_GETTY:=$(call qstrip,$(BR2_TARGET_GENERIC_GETTY_PORT))
TARGET_GENERIC_GETTY_BAUDRATE:=$(call qstrip,$(BR2_TARGET_GENERIC_GETTY_BAUDRATE))
--
1.7.2.5
^ permalink raw reply related
* [Buildroot] [PATCH] docs/manual: small fixes and enhancements to adding generic packages
From: Yann E. MORIN @ 2012-12-30 20:47 UTC (permalink / raw)
To: buildroot
Add overall description of LIBFOO_DEVICES and LIBFOO_PERMISSIONS.
Fix line numbers.
Cc: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
docs/manual/adding-packages-generic.txt | 32 +++++++++++++++++++-----------
1 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/docs/manual/adding-packages-generic.txt b/docs/manual/adding-packages-generic.txt
index 6c1c35e..0759d4f 100644
--- a/docs/manual/adding-packages-generic.txt
+++ b/docs/manual/adding-packages-generic.txt
@@ -53,30 +53,32 @@ system is based on hand-written Makefiles or shell scripts.
37: $(eval $(generic-package))
--------------------------------
-The Makefile begins on line 6 to 8 with metadata information: the
+The Makefile begins on line 6 to 10 with metadata information: the
version of the package (+LIBFOO_VERSION+), the name of the
-tarball containing the package (+LIBFOO_SOURCE+) and the
-Internet location at which the tarball can be downloaded
-(+LIBFOO_SITE+). All variables must start with the same prefix,
-+LIBFOO_+ in this case. This prefix is always the uppercased
-version of the package name (see below to understand where the package
-name is defined).
-
-On line 9, we specify that this package wants to install something to
+tarball containing the package (+LIBFOO_SOURCE+) the
+Internet location at which the tarball can be downloaded from
+(+LIBFOO_SITE+), the license (+LIBFOO_LICENSE+) and file with the
+license text (+LIBFOO_LICENSE_FILES+). All variables must start with
+the same prefix, +LIBFOO_+ in this case. This prefix is always the
+uppercased version of the package name (see below to understand where
+the package name is defined).
+
+On line 11, we specify that this package wants to install something to
the staging space. This is often needed for libraries, since they must
install header files and other development files in the staging space.
This will ensure that the commands listed in the
+LIBFOO_INSTALL_STAGING_CMDS+ variable will be executed.
-On line 10, we specify the list of dependencies this package relies
+On line 12, we specify the list of dependencies this package relies
on. These dependencies are listed in terms of lower-case package names,
which can be packages for the target (without the +host-+
prefix) or packages for the host (with the +host-+) prefix).
Buildroot will ensure that all these packages are built and installed
'before' the current package starts its configuration.
-The rest of the Makefile defines what should be done at the different
-steps of the package configuration, compilation and installation.
+The rest of the Makefile, lines 14..27, defines what should be done
+at the different steps of the package configuration, compilation and
+installation.
+LIBFOO_BUILD_CMDS+ tells what steps should be performed to
build the package. +LIBFOO_INSTALL_STAGING_CMDS+ tells what
steps should be performed to install the package in the staging space.
@@ -87,7 +89,13 @@ All these steps rely on the +$(@D)+ variable, which
contains the directory where the source code of the package has been
extracted.
-Finally, on line 35, we call the +generic-package+ which
+On line 29..31, we define a device-node file used by this package
+(+LIBFOO_DEVICES+).
+
+On line 33..35, we define the permissions to set to specific files
+installed by this package (+LIBFOO_PERMISSIONS+).
+
+Finally, on line 37, we call the +generic-package+ function, which
generates, according to the variables defined previously, all the
Makefile code necessary to make your package working.
--
1.7.2.5
^ permalink raw reply related
* [Buildroot] [PATCH] docs/manual: small fixes and enhancements to adding generic packages
From: Samuel Martin @ 2012-12-30 21:00 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1356900441-15304-1-git-send-email-yann.morin.1998@free.fr>
Hi Yann, all,
2012/12/30 Yann E. MORIN <yann.morin.1998@free.fr>:
> Add overall description of LIBFOO_DEVICES and LIBFOO_PERMISSIONS.
> Fix line numbers.
>
> Cc: Samuel Martin <s.martin49@gmail.com>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Regards,
--
Samuel
^ permalink raw reply
* [Buildroot] [pull request] Pull request for branch for-master/misc-fixes
From: Samuel Martin @ 2012-12-30 21:33 UTC (permalink / raw)
To: buildroot
Hello,
Here are few random fixes, some of them are related to python handling
from the host system.
The patches handling the python binary provided by the host system are
also an RFC that summarize few discussions on the IRC channel.
The following changes since commit 8850c522172acc6586c32a30f2dee79501293636:
docs/manual: do not suggest to create a symlink for shared download directory (2012-12-29 22:42:41 +0100)
are available in the git repository at:
git at github.com:tSed/buildroot.git for-master/misc-fixes
for you to fetch changes up to 92a1a6fcc94a58f445133e8e4cf1ae47c73e0eae:
manual: add host python2 dependency section (2012-12-30 20:44:12 +0100)
----------------------------------------------------------------
Samuel Martin (8):
matchbox-lib: fix license info
fluxbox: fix build against imlib2
package/Makefile.in: update/fix HOST_PATH variable
package/pkg-cmake.mk: make sure $(HOST_PATH) is in the PATH at configure time
dependencies: build a host python2 if no suitable one can be found
scons: add host-python2-if-needed dependency
scons: ensure $(HOST_DIR)/usr/bin is in the PATH when invoking $(SCONS)
manual: add host python2 dependency section
docs/manual/adding-packages-tips.txt | 38 +++++++++++++++++++++++
package/Makefile.in | 2 +-
package/fluxbox/fluxbox-1.3.2-fix-configure.patch | 19 ++++++++++++
package/fluxbox/fluxbox.mk | 10 +++++-
package/matchbox/matchbox-lib/matchbox-lib.mk | 2 +-
package/pkg-cmake.mk | 5 +--
package/scons/scons.mk | 10 ++++--
support/dependencies/check-host-python2.mk | 18 +++++++++++
support/dependencies/check-host-python2.sh | 13 ++++++++
support/dependencies/dependencies.sh | 2 +-
10 files changed, 110 insertions(+), 9 deletions(-)
create mode 100644 package/fluxbox/fluxbox-1.3.2-fix-configure.patch
create mode 100644 support/dependencies/check-host-python2.mk
create mode 100755 support/dependencies/check-host-python2.sh
Yours,
--
Samuel
^ permalink raw reply
* [Buildroot] [PATCH 1/8] matchbox-lib: fix license info
From: Samuel Martin @ 2012-12-30 21:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1356903063.git.s.martin49@gmail.com>
---
package/matchbox/matchbox-lib/matchbox-lib.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/matchbox/matchbox-lib/matchbox-lib.mk b/package/matchbox/matchbox-lib/matchbox-lib.mk
index 7730d94..d18df6b 100644
--- a/package/matchbox/matchbox-lib/matchbox-lib.mk
+++ b/package/matchbox/matchbox-lib/matchbox-lib.mk
@@ -7,7 +7,7 @@
MATCHBOX_LIB_VERSION = 1.9
MATCHBOX_LIB_SOURCE = libmatchbox-$(MATCHBOX_LIB_VERSION).tar.bz2
MATCHBOX_LIB_SITE = http://downloads.yoctoproject.org/releases/matchbox/libmatchbox/$(MATCHBOX_LIB_VERSION)
-MATCHBOX_LIB_LICENSE = LGPLv2.1
+MATCHBOX_LIB_LICENSE = LGPLv2.1+
MATCHBOX_LIB_LICENSE_FILES = COPYING
MATCHBOX_LIB_INSTALL_STAGING = YES
MATCHBOX_LIB_DEPENDENCIES = host-pkgconf expat xlib_libXext
--
1.8.0.3
^ permalink raw reply related
* [Buildroot] [PATCH 2/8] fluxbox: fix build against imlib2
From: Samuel Martin @ 2012-12-30 21:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1356903063.git.s.martin49@gmail.com>
* fix configure.in to take care of the given imlib2-prefix
* disable imlib2 support if imlib2 is not part of the selection
---
package/fluxbox/fluxbox-1.3.2-fix-configure.patch | 19 +++++++++++++++++++
package/fluxbox/fluxbox.mk | 10 +++++++++-
2 files changed, 28 insertions(+), 1 deletion(-)
create mode 100644 package/fluxbox/fluxbox-1.3.2-fix-configure.patch
diff --git a/package/fluxbox/fluxbox-1.3.2-fix-configure.patch b/package/fluxbox/fluxbox-1.3.2-fix-configure.patch
new file mode 100644
index 0000000..2cb8273
--- /dev/null
+++ b/package/fluxbox/fluxbox-1.3.2-fix-configure.patch
@@ -0,0 +1,19 @@
+Avoid to call the imlib2-config that may be installed on the host system
+(even when --with-imlib2-prefix or --with-imlib2-exec-prefix is passed to
+the configure script), which totally screws up the resulting linker flags.
+
+Inspired by: http://git.fluxbox.org/fluxbox.git/commit/?id=b178bed60b5bd8b2c9ed0cbc67fd729ff3820589
+
+Signed-off-by: Samuel Martin <s.martin49@gmail.com>
+
+--- fluxbox-1.3.2.orig/configure.in 2012-10-21 16:11:59.445749396 +0200
++++ fluxbox-1.3.2/configure.in 2012-10-21 16:35:27.658390856 +0200
+@@ -443,8 +443,6 @@ if test x$enable_imlib2 = "xyes"; then
+ [
+ IMLIB2=true
+ AC_DEFINE(HAVE_IMLIB2, [], [Imlib2 support])
+- IMLIB2_LIBS=`imlib2-config --libs`
+- IMLIB2_CFLAGS=`imlib2-config --cflags`
+ LIBS="$LIBS $IMLIB2_LIBS"
+ CXXFLAGS="$CXXFLAGS $IMLIB2_CFLAGS"
+ ], [ AC_MSG_RESULT(no)]
diff --git a/package/fluxbox/fluxbox.mk b/package/fluxbox/fluxbox.mk
index 356c5a2..04ffb91 100644
--- a/package/fluxbox/fluxbox.mk
+++ b/package/fluxbox/fluxbox.mk
@@ -10,11 +10,19 @@ FLUXBOX_SITE = http://downloads.sourceforge.net/project/fluxbox/fluxbox/$(FLUXBO
FLUXBOX_LICENSE = MIT
FLUXBOX_LICENSE_FILES = COPYING
+FLUXBOX_AUTORECONF = YES
+
FLUXBOX_CONF_OPT = --x-includes=$(STAGING_DIR)/usr/include/X11 \
--x-libraries=$(STAGING_DIR)/usr/lib
-
FLUXBOX_DEPENDENCIES = xlib_libX11 $(if $(BR2_PACKAGE_LIBICONV),libiconv)
+ifeq ($(BR2_PACKAGE_IMLIB2),y)
+FLUXBOX_CONF_OPT += --enable-imlib2 --with-imlib2-prefix=$(STAGING_DIR)/usr
+FLUXBOX_DEPENDENCIES += imlib2
+else
+FLUXBOX_CONF_OPT += --disable-imlib2
+endif
+
define FLUXBOX_INSTALL_XSESSION_FILE
[ -f $(TARGET_DIR)/root/.xsession ] || $(INSTALL) -m 0755 -D \
package/fluxbox/xsession $(TARGET_DIR)/root/.xsession
--
1.8.0.3
^ permalink raw reply related
* [Buildroot] [PATCH 3/8] package/Makefile.in: update/fix HOST_PATH variable
From: Samuel Martin @ 2012-12-30 21:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1356903063.git.s.martin49@gmail.com>
---
package/Makefile.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/Makefile.in b/package/Makefile.in
index cc8f320..dd04e25 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -165,7 +165,7 @@ HOST_CFLAGS ?= -O2
HOST_CFLAGS += $(HOST_CPPFLAGS)
HOST_CXXFLAGS += $(HOST_CFLAGS)
HOST_LDFLAGS += -L$(HOST_DIR)/lib -L$(HOST_DIR)/usr/lib -Wl,-rpath,$(HOST_DIR)/usr/lib
-HOST_PATH=$(HOST_DIR)/bin:$(HOST_DIR)/usr/bin:$(PATH)
+HOST_PATH="$(HOST_DIR)/bin:$(HOST_DIR)/usr/bin:$(HOST_DIR)/usr/sbin/:$(PATH)"
# hostcc version as an integer - E.G. 4.3.2 => 432
HOSTCC_VERSION:=$(shell $(HOSTCC_NOCCACHE) --version | \
--
1.8.0.3
^ permalink raw reply related
* [Buildroot] [PATCH 4/8] package/pkg-cmake.mk: make sure $(HOST_PATH) is in the PATH at configure time
From: Samuel Martin @ 2012-12-30 21:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1356903063.git.s.martin49@gmail.com>
---
package/pkg-cmake.mk | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/package/pkg-cmake.mk b/package/pkg-cmake.mk
index 626a0b0..1e8302f 100644
--- a/package/pkg-cmake.mk
+++ b/package/pkg-cmake.mk
@@ -62,7 +62,8 @@ ifeq ($(5),target)
define $(2)_CONFIGURE_CMDS
(cd $$($$(PKG)_BUILDDIR) && \
rm -f CMakeCache.txt && \
- $$($$(PKG)_CONF_ENV) $(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
+ PATH="$(TARGET_PATH)" $$($$(PKG)_CONF_ENV) \
+ $(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
-DCMAKE_TOOLCHAIN_FILE="$$(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake" \
-DCMAKE_INSTALL_PREFIX="/usr" \
$$($$(PKG)_CONF_OPT) \
@@ -74,7 +75,7 @@ else
define $(2)_CONFIGURE_CMDS
(cd $$($$(PKG)_BUILDDIR) && \
rm -f CMakeCache.txt && \
- $(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
+ PATH="$(HOST_PATH)" $(HOST_DIR)/usr/bin/cmake $$($$(PKG)_SRCDIR) \
-DCMAKE_INSTALL_SO_NO_EXE=0 \
-DCMAKE_FIND_ROOT_PATH="$$(HOST_DIR)" \
-DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM="BOTH" \
--
1.8.0.3
^ permalink raw reply related
* [Buildroot] [PATCH 5/8] dependencies: build a host python2 if no suitable one can be found
From: Samuel Martin @ 2012-12-30 21:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1356903063.git.s.martin49@gmail.com>
Some distros now comes with only python3 installed, with or without a
/usr/bin/python pointing to python3.
So, /usr/bin/python may refer to either python2 or python3.
This may have some bad consequences for packages that uses some
non python{2,3}-friendly scripts in their build system (eg. in install
or post-install scripts).
This patch checks for a suitable python2 version (2.6 or 2.7) on the host
system, and:
* if a valid python2 interperter is found on the host system, then:
- a symlink pointing to the found python2 interpreter is created in the
buildroot host tree at the beginning of the build;
- a make target host-python2-if-needed is set to '$(HOST_DIR)/usr/bin/python'.
This way, if the host-python package is built later, the symlink will be
automatically overriden by the host-python install rules.
* if no valid python2 interperter is found on the host system, then:
- a make target host-python2-if-needed is set to 'host-python'.
Note 1: The symlink is checked and created if necessary at the beginning of
each build.
Note 2: Since there is no target named '$(HOST_DIR)/usr/bin/python' in the
python makefiles, there is no need for removing the symlink before
installing the host-pyhton package.
Note 3: The host-python is only built when necessary.
This also means that in the case there is no python2 interperter
available on the host system, there won't any host python2 interperter
until the host-python package is built.
Note 4: Any package containing some non python{2,3}-friendly scripts should:
- have 'host-python2-if-needed' in its *_DEPENDENCIES list;
- set and add to their build/install environment, either
PATH="$(HOST_PATH)" or PATH="$(TARGET_PATH)".
A (good) side effect of this patch is getting rid of any host python dependency.
Buildroot can run on a host without python, or with a too old python2 version,
or with only python3.
In any case where a host python2 interpreter is expected to run some build or
install scripts, 'host-python2-if-needed' should be added to the dependency
list.
With this patch, the host python2 interpreter is either found in the host
system, or build by Buildroot. So, we can drop the python dependency check.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
support/dependencies/check-host-python2.mk | 18 ++++++++++++++++++
support/dependencies/check-host-python2.sh | 13 +++++++++++++
support/dependencies/dependencies.sh | 2 +-
3 files changed, 32 insertions(+), 1 deletion(-)
create mode 100644 support/dependencies/check-host-python2.mk
create mode 100755 support/dependencies/check-host-python2.sh
diff --git a/support/dependencies/check-host-python2.mk b/support/dependencies/check-host-python2.mk
new file mode 100644
index 0000000..5bc2986
--- /dev/null
+++ b/support/dependencies/check-host-python2.mk
@@ -0,0 +1,18 @@
+PYTHON2 = $(call suitable-host-package,python2,$(HOST_DIR)/usr/bin/python)
+
+ifeq ($(PYTHON2),)
+host-python2-if-needed: host-python
+else
+host-python2-if-needed: $(HOST_DIR)/usr/bin/python
+# Create the python symlink once for all at the beginning of the build.
+DEPENDENCIES_HOST_PREREQ += host-python2-symlink
+endif
+
+# host-python install rules override the symlink created here.
+# So, there is no need to patch the python package to remove the symlink
+# before installing itself.
+host-python2-symlink:
+ @mkdir -p $(HOST_DIR)/usr/bin
+ test -x "$(HOST_DIR)/usr/bin/python" -a \
+ "$(PYTHON2)" = "$(HOST_DIR)/usr/bin/python" || \
+ $(HOSTLN) -sf "$(PYTHON2)" "$(HOST_DIR)/usr/bin/python"
diff --git a/support/dependencies/check-host-python2.sh b/support/dependencies/check-host-python2.sh
new file mode 100755
index 0000000..a340674
--- /dev/null
+++ b/support/dependencies/check-host-python2.sh
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+candidates="${@} python python2"
+
+for candidate in ${candidates} ; do
+ which "${candidate}" &>/dev/null || continue
+ # restrict version of python2 to 2.6 or 2.7
+ if "${candidate}" --version 2>&1 | grep -q 'Python 2\.[6-7]\..*' ; then
+ # found a valid candidate, so quit now
+ echo $(which "${candidate}")
+ exit
+ fi
+done
diff --git a/support/dependencies/dependencies.sh b/support/dependencies/dependencies.sh
index 7a02512..0a5cf8b 100755
--- a/support/dependencies/dependencies.sh
+++ b/support/dependencies/dependencies.sh
@@ -131,7 +131,7 @@ if ! $SHELL --version 2>&1 | grep -q '^GNU bash'; then
fi;
# Check that a few mandatory programs are installed
-for prog in awk bison flex msgfmt makeinfo patch gzip bzip2 perl tar wget cpio python unzip rsync ${DL_TOOLS} ; do
+for prog in awk bison flex msgfmt makeinfo patch gzip bzip2 perl tar wget cpio unzip rsync ${DL_TOOLS} ; do
if ! which $prog > /dev/null ; then
/bin/echo -e "\nYou must install '$prog' on your build machine";
if test $prog = "makeinfo" ; then
--
1.8.0.3
^ permalink raw reply related
* [Buildroot] [PATCH 6/8] scons: add host-python2-if-needed dependency
From: Samuel Martin @ 2012-12-30 21:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1356903063.git.s.martin49@gmail.com>
Also, ensure $(HOST_DIR)/usr/bin is in the PATH during the configure phase.
---
package/scons/scons.mk | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/package/scons/scons.mk b/package/scons/scons.mk
index 79fd6b1..e3ada92 100644
--- a/package/scons/scons.mk
+++ b/package/scons/scons.mk
@@ -4,12 +4,16 @@ SCONS_SITE = http://downloads.sourceforge.net/project/scons/scons/$(SCONS_VERSIO
SCONS_LICENSE = MIT
SCONS_LICENSE_FILES = LICENSE.txt
+# Because Scons is not python3-friendly, we have to ensure that
+HOST_SCONS_DEPENDENCIES = host-python2-if-needed
+
define HOST_SCONS_BUILD_CMDS
- (cd $(@D); python setup.py build)
+ (cd $(@D); $(HOST_CONFIGURE_OPTS) python setup.py build)
endef
define HOST_SCONS_INSTALL_CMDS
- (cd $(@D); python setup.py install --prefix=$(HOST_DIR)/usr \
+ (cd $(@D) ; $(HOST_CONFIGURE_OPTS) python setup.py install \
+ --prefix=$(HOST_DIR)/usr \
--install-lib=$(HOST_DIR)/usr/lib/scons-$(SCONS_VERSION))
endef
--
1.8.0.3
^ permalink raw reply related
* [Buildroot] [PATCH 7/8] scons: ensure $(HOST_DIR)/usr/bin is in the PATH when invoking $(SCONS)
From: Samuel Martin @ 2012-12-30 21:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1356903063.git.s.martin49@gmail.com>
---
package/scons/scons.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/scons/scons.mk b/package/scons/scons.mk
index e3ada92..e828588 100644
--- a/package/scons/scons.mk
+++ b/package/scons/scons.mk
@@ -20,4 +20,4 @@ endef
$(eval $(host-generic-package))
# variables used by other packages
-SCONS = $(HOST_DIR)/usr/bin/scons
+SCONS = PATH=$(HOST_PATH) $(HOST_DIR)/usr/bin/scons
--
1.8.0.3
^ permalink raw reply related
* [Buildroot] [PATCH 8/8] manual: add host python2 dependency section
From: Samuel Martin @ 2012-12-30 21:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1356903063.git.s.martin49@gmail.com>
---
docs/manual/adding-packages-tips.txt | 38 ++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/docs/manual/adding-packages-tips.txt b/docs/manual/adding-packages-tips.txt
index acdee40..4a971cb 100644
--- a/docs/manual/adding-packages-tips.txt
+++ b/docs/manual/adding-packages-tips.txt
@@ -62,3 +62,41 @@ FOO_SITE = http://github.com/<user>/<package>/tarball/<branch>
Note that the name of the tarball is the default +foo-1234567.tar.gz+
so it is not necessary to specify it in the +.mk+ file.
+
+[[python2-and-package-build-env]]
+Host python2 dependency and package environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Some packages provide some python scripts as part of their
+build/install system.
+
+Unfortunately, those python scripts are not always python3-friendly.
+So, a python2 interpreter on the host system is a prerequisite for
+those packages. Besides, their build system may call them invoking
++python <some script> ...+ which have bad consequences if the +python+
+command does not exist or if it call a python3 interperter instead of
+a python2 one.
+
+Buildroot provides a way to handle this case, without requiring to
+patch anything in the package sources.
+
+* add +host-python2-if-needed+ to the +*_DEPENDENCIES+ list;
+* make sure the +PATH+ environment variable contains
+ +$(HOST_DIR)/usr/bin+.
+
+.Notes
+- This is automatic if the package relies on the _autotools_ or
+ _cmake_ infrastructure and does not need to override some of the
+ configure, build or install commands.
+- Otherwise (i.e. the package uses the _generic_ infrastructure or
+ overrides some of the configure, build or install commands), you
+ should ensure +PATH=$(HOST_PATH)+ or +PATH=$(TARGET_PATH)+ to
+ overridden commands.
+- The +PATH+ environment variable is correctly set in the variables
+ +TARGET_CONFIGURE_OPTS+ or +TARGET_MAKE_ENV+ as well as in their
+ +HOST+ variants.
+- For package relying on http://www.scons.org[Scons] build system,
+ it should depend on +host-scons+ and use the +$(SCONS)+ variable.
+ This will automatically take care of the host python2 dependency
+ since http://www.scons.org[Scons] does not support python3 yet
+ (see http://www.scons.org/doc/production/HTML/scons-user/c95.html#AEN102).
--
1.8.0.3
^ permalink raw reply related
* [Buildroot] [git commit] docs/manual: small fixes and enhancements to adding generic packages
From: Peter Korsgaard @ 2012-12-30 21:39 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=f1d44593a04ff3be981c8a3b01a502f0b18193ee
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Add overall description of LIBFOO_DEVICES and LIBFOO_PERMISSIONS.
Fix line numbers.
Cc: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
docs/manual/adding-packages-generic.txt | 32 +++++++++++++++++++-----------
1 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/docs/manual/adding-packages-generic.txt b/docs/manual/adding-packages-generic.txt
index 6c1c35e..0759d4f 100644
--- a/docs/manual/adding-packages-generic.txt
+++ b/docs/manual/adding-packages-generic.txt
@@ -53,30 +53,32 @@ system is based on hand-written Makefiles or shell scripts.
37: $(eval $(generic-package))
--------------------------------
-The Makefile begins on line 6 to 8 with metadata information: the
+The Makefile begins on line 6 to 10 with metadata information: the
version of the package (+LIBFOO_VERSION+), the name of the
-tarball containing the package (+LIBFOO_SOURCE+) and the
-Internet location at which the tarball can be downloaded
-(+LIBFOO_SITE+). All variables must start with the same prefix,
-+LIBFOO_+ in this case. This prefix is always the uppercased
-version of the package name (see below to understand where the package
-name is defined).
-
-On line 9, we specify that this package wants to install something to
+tarball containing the package (+LIBFOO_SOURCE+) the
+Internet location at which the tarball can be downloaded from
+(+LIBFOO_SITE+), the license (+LIBFOO_LICENSE+) and file with the
+license text (+LIBFOO_LICENSE_FILES+). All variables must start with
+the same prefix, +LIBFOO_+ in this case. This prefix is always the
+uppercased version of the package name (see below to understand where
+the package name is defined).
+
+On line 11, we specify that this package wants to install something to
the staging space. This is often needed for libraries, since they must
install header files and other development files in the staging space.
This will ensure that the commands listed in the
+LIBFOO_INSTALL_STAGING_CMDS+ variable will be executed.
-On line 10, we specify the list of dependencies this package relies
+On line 12, we specify the list of dependencies this package relies
on. These dependencies are listed in terms of lower-case package names,
which can be packages for the target (without the +host-+
prefix) or packages for the host (with the +host-+) prefix).
Buildroot will ensure that all these packages are built and installed
'before' the current package starts its configuration.
-The rest of the Makefile defines what should be done at the different
-steps of the package configuration, compilation and installation.
+The rest of the Makefile, lines 14..27, defines what should be done
+at the different steps of the package configuration, compilation and
+installation.
+LIBFOO_BUILD_CMDS+ tells what steps should be performed to
build the package. +LIBFOO_INSTALL_STAGING_CMDS+ tells what
steps should be performed to install the package in the staging space.
@@ -87,7 +89,13 @@ All these steps rely on the +$(@D)+ variable, which
contains the directory where the source code of the package has been
extracted.
-Finally, on line 35, we call the +generic-package+ which
+On line 29..31, we define a device-node file used by this package
+(+LIBFOO_DEVICES+).
+
+On line 33..35, we define the permissions to set to specific files
+installed by this package (+LIBFOO_PERMISSIONS+).
+
+Finally, on line 37, we call the +generic-package+ function, which
generates, according to the variables defined previously, all the
Makefile code necessary to make your package working.
^ 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