* [Buildroot] Autotest infrastructure (a bit of off-topic: git repo URL)
From: Javier Viguera @ 2012-11-08 16:21 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509BC913.3080902@mind.be>
Hi Arnout,
I attended the other day to your talk on "upgrading without bricking"
(congrats for that, i learned a lot) and you mentioned a repo where you
have started collecting some tools/scripts to do the job.
Could you remind me that repo URL? I shouldn't have trust i would
remember it some days after.
Sorry the rest for the thread hijacking.
--
Javier Viguera
Software Engineer
Digi International? Spain S.A.U.
^ permalink raw reply
* [Buildroot] Udev on a live CD system does not appear to populate /dev
From: Stefan Fröberg @ 2012-11-08 16:20 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509BD78A.8050908@macrium.com>
8.11.2012 18:02, Antony Vennard kirjoitti:
> Hi Stefan,
>
> Thanks for that. I have followed your instructions for making a live cd
> manually with mkisofs - actually this is helpful since a later job is to
> add UEFI booting to the disk, which is easier this way (although I am
> going to look at modifying buildroot, if I can).
>
> I am using grub, and have modified my grub command line to use:
>
> title LiveCD
> kernel /vmlinuz vga=0x317
> initrd /initramfs.bz2
>
> The kernel has bz2, xz and gzip initramfs support built in - so all good
> there. However, the kernel complains there's no root parameter. What
> should I specify for this?
root=/dev/ram0
So that would be:
kernel /vmlinuz vga=0x317 root=/dev/ram0
If you want to you can give it ramdisk_size parameter (from
https://www.kernel.org/doc/Documentation/kernel-parameters.txt)
but that should not be nowadays necessary.
Just make sure that you have enough ram memory for total amount of the
size (uncompressed) of your initramfs + some ram needed to actually run
your applications.
and make sure that /dev/ram0 is in fs/skeleton/dev (or output/target/dev
if you hollowed my instructions) and
regenerate initramfs
If you hit the limit of your CD disc (or RAM) but want to still add some
more stuff into it then
me know. I have solved it, but like I said, it's hackis and dirty method :-)
Best regards
Stefan
> Thanks,
>
> Antony
>
> On 08/11/2012 12:35, Stefan Fr?berg wrote:
>> Hi Antony
>>
>> Just one guestion: What bootloader are you using for your Live CD ?
>> (I use grub)
>>
>> 8.11.2012 11:56, Antony Vennard kirjoitti:
>>> Hi All,
>>>
>>> I'm not using initramfs - I'm using the ISO 9660 target which as far
>>> as I can see produces an initrd, a kernel and an ext2 raw image which
>>> it mounts as a ramdisk. If I select the initramfs options, the cpio
>>> filesystem is generated prior to the iso9660 one, *but the initramfs
>>> afterwards!* Which means, as far as I can see, that initramfs would
>>> not be placed on the disk - unless buildroot manipulates the iso
>>> filesystem post creation? I could of course mkisofs myself, but I was
>>> trying to avoid that - although if this fixes udev, I'll do it.
>>>
>> Keep in mind that the buildroot way of making initramfs (that is if you
>> select intramfs from menuconfig) is
>> to embed your initramfs directly into kernel.
>>
>> There are three disadvantages in here:
>>
>> 1 ) It will make your kernel fatter
>> 2 ) It will makes things more complicated than necessary
>> You might have two initramfs settings: One that is embedded directly
>> into your kernel and
>> another that you have made by hand by yourself. And it's very possible
>> that they could have conflicting stuff between them
>> You can have several initramfs files (at least with grub bootloader),
>> the last ones overlaying the first ones, in order.
>> 3 ) It will makes less flexibe.
>>
>> All kernels since 2.6 have initramfs inside them, it's just that by
>> default that environment is empty.
>>
>> Embedding initramfs directly to kernel might be good for those users who
>> don't use any bootloader or are using a bootloader which can't
>> be feeded external, separate initramfs file(s) (like grub) and want to
>> have minimal system always available (as piggybacked inside kernel).
>>
>>
>>> I've nothing /dev related in my fs/skeleton, and only the default
>>> values in device_table.txt. Since I'm using udev, I did expect it
>>> would populate everything it needed in /dev - although unless I add
>>> entries for null, console and a tty into device_table.txt, I end up
>>> with a distribution that loops forever saying "could not find
>>> /dev/tty1" (if I've configured tty1 as the location for getty for
>>> example). I can't mitigate this by re-writing the inittab to launch
>>> getty "once" as opposed to respawn, since buildroot rewrites that -
>>> and askfirst:/bin/sh works, except that the respawn error messages are
>>> written all over /dev/console, making it unusable...!
>>>
>>> By the sounds of things this is wrong, but I'm currently attempting to
>>> preconfigure some devices in device_table.txt - e.g. /dev/null,
>>> /dev/urandom et al pseudo devices, and I'm borrowing Ubuntu's rules.d
>>> to see if these are any more effective than Fedora's. Leaving
>>> device_table.txt as its default causes the tty1 missing loop. I am not
>>> expecting this to work - I cannot see how udev rules differ greatly
>>> between distributions - just eliminating it as a possible cause.
>>>
>>> Any further ideas as to what I can try? Is mdev a better choice?
>>>
>> Well mdev is at least easier to configure than udev.
>>
>> The only thing you must make sure in your init process is that /proc and
>> /sys are mounted as early as possible (/etc/inittab is good place for that)
>> and that echo /sbin/mdev > /proc/sys/kernel/hotplug is also somewhere
>> in /etc/init.d/rcS (maybe at the start of that file)
>>
>> And check that you have etc/mdev.conf and etc/init.d/S10mdev (witch is
>> called by /etc/init.d/rcS)
>>
>> This is what I would do (and have done with my live CD)
>> Forget the buildroot way of making initramfs for now and see if you can
>> construct live CD by hand:
>>
>> 1 ) make clean
>>
>> 2 ) make sure you have all the needed init stuff in fs/skeleton/etc
>> directory (inittab, init.d/rcS, init.d/S* files etc.....)
>> also make sure that sbin/init is a symlink to /bin/busybox
>> (I have also symlink of init --> /bin/busybox in top of fs/skeleton but
>> I not sure if that is stricly needed ...
>> I think kernel should be looking from /sbin/init if no other init found)
>>
>> 3 ) do make menuconfig as you would normally but remember to unselect
>> cpio, initramfs and iso9660 from menuconfig
>> remember to select grub from under Bootloader section if you
>> don't already have it
>> don't select too much of stuff even if you have massive amounts
>> of RAM in your test systems.
>> reason being that you are making initramfs later here from your
>> output/target directory and if you have massive
>> amount's of stuff in there then it will take forever to boot. (I
>> have managed to do live CD with massive amounts of stuff on it and
>> booting fast with only 192 MB RAM but that needed some major hacking)
>>
>> 4 ) do make linux-menuconfig and check that under General setup the
>> setting Initramfs source files is empty
>> also check the compression support here that you want to use for
>> your external initramfs (let's suppose its' the default GZ for now)
>>
>> 5 ) do make
>>
>> 6 ) after buildroot has finished make sure that everything is okay in
>> your output/target (check especially boot/ etc/ and /dev directory)
>> also make sure you have /boot/grub/menu.lst or /boot/grub/grub.conf
>> (the other is usually just symlink to other) and check it's settings
>> (If you are not familiar with grub then I can help with it's
>> settings, especially important is the line where you tell grub the external
>> initramfs file)
>> remove the symlink (iso9660 format does not support symlinks)
>>
>> 7 ) Create directory where you want to put your kernel & bootloader
>> (a.ka. the whole contents of /boot dir) and external initramfs file
>> that is generated next:
>>
>> mkdir /livecd && cp -r output/target/boot /livecd
>>
>> 8 ) from output/target dir do find . -not \( -path "./boot" -prune
>> \) -print0 | cpio --null -ov --format=newc | gzip -9 > /livecd/initramfs.gz
>> (we don't need boot directory inside initramfs. it needs to stay outside
>> of it. that why it was copied previously)
>>
>> 9 ) make iso9660 normally from the contents of your /livecd
>> mkdir /livecd_output && cd /livecd && mkisofs --joliet -R -b
>> boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4
>> -boot-info-table -iso-level 4 -hide-rr-moved -c boot.catalog -o
>> /livecd_output/your_livecd.iso .
>>
>> (remember that . at the end)
>>
>> 10) burn the iso to CD or even better use qemu or VirtualBox to boot
>> your iso without wasting CD disc.
>>
>> If this manual way worked then next try buildroot way.
>>
>> Best regards
>> Stefan
>>
>>> Thanks for your help,
>>>
>>> Antony
>>>
>>> ________________
>>>
>>> Macrium? Software is a trading name of Paramount Software UK Ltd,
>>> Registered in England and Wales Number 02973414
>>> Registered Office: Kilburn House, Manchester Science Park, Lloyd St.
>>> North, Manchester M15 6SE United Kingdom
>>>
>>> The information contained in this e-mail is confidential, privileged,
>>> or otherwise protected from disclosure. It is intended only for the
>>> use of the authorized individual as indicated in the e-mail. Any
>>> unauthorized disclosure, copying, distribution or taking of any action
>>> based on the contents of this material is strictly prohibited.
>>>
>>> If you have received this e-mail in error, please delete it immediately.
>>>
>>>
>>>
>>> _______________________________________________
>>> buildroot mailing list
>>> buildroot at busybox.net
>>> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply
* [Buildroot] Udev on a live CD system does not appear to populate /dev
From: Antony Vennard @ 2012-11-08 16:02 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509BA71B.6020009@petroprogram.com>
Hi Stefan,
Thanks for that. I have followed your instructions for making a live cd
manually with mkisofs - actually this is helpful since a later job is to
add UEFI booting to the disk, which is easier this way (although I am
going to look at modifying buildroot, if I can).
I am using grub, and have modified my grub command line to use:
title LiveCD
kernel /vmlinuz vga=0x317
initrd /initramfs.bz2
The kernel has bz2, xz and gzip initramfs support built in - so all good
there. However, the kernel complains there's no root parameter. What
should I specify for this?
Thanks,
Antony
On 08/11/2012 12:35, Stefan Fr?berg wrote:
> Hi Antony
>
> Just one guestion: What bootloader are you using for your Live CD ?
> (I use grub)
>
> 8.11.2012 11:56, Antony Vennard kirjoitti:
>> Hi All,
>>
>> I'm not using initramfs - I'm using the ISO 9660 target which as far
>> as I can see produces an initrd, a kernel and an ext2 raw image which
>> it mounts as a ramdisk. If I select the initramfs options, the cpio
>> filesystem is generated prior to the iso9660 one, *but the initramfs
>> afterwards!* Which means, as far as I can see, that initramfs would
>> not be placed on the disk - unless buildroot manipulates the iso
>> filesystem post creation? I could of course mkisofs myself, but I was
>> trying to avoid that - although if this fixes udev, I'll do it.
>>
>
> Keep in mind that the buildroot way of making initramfs (that is if you
> select intramfs from menuconfig) is
> to embed your initramfs directly into kernel.
>
> There are three disadvantages in here:
>
> 1 ) It will make your kernel fatter
> 2 ) It will makes things more complicated than necessary
> You might have two initramfs settings: One that is embedded directly
> into your kernel and
> another that you have made by hand by yourself. And it's very possible
> that they could have conflicting stuff between them
> You can have several initramfs files (at least with grub bootloader),
> the last ones overlaying the first ones, in order.
> 3 ) It will makes less flexibe.
>
> All kernels since 2.6 have initramfs inside them, it's just that by
> default that environment is empty.
>
> Embedding initramfs directly to kernel might be good for those users who
> don't use any bootloader or are using a bootloader which can't
> be feeded external, separate initramfs file(s) (like grub) and want to
> have minimal system always available (as piggybacked inside kernel).
>
>
>> I've nothing /dev related in my fs/skeleton, and only the default
>> values in device_table.txt. Since I'm using udev, I did expect it
>> would populate everything it needed in /dev - although unless I add
>> entries for null, console and a tty into device_table.txt, I end up
>> with a distribution that loops forever saying "could not find
>> /dev/tty1" (if I've configured tty1 as the location for getty for
>> example). I can't mitigate this by re-writing the inittab to launch
>> getty "once" as opposed to respawn, since buildroot rewrites that -
>> and askfirst:/bin/sh works, except that the respawn error messages are
>> written all over /dev/console, making it unusable...!
>>
>> By the sounds of things this is wrong, but I'm currently attempting to
>> preconfigure some devices in device_table.txt - e.g. /dev/null,
>> /dev/urandom et al pseudo devices, and I'm borrowing Ubuntu's rules.d
>> to see if these are any more effective than Fedora's. Leaving
>> device_table.txt as its default causes the tty1 missing loop. I am not
>> expecting this to work - I cannot see how udev rules differ greatly
>> between distributions - just eliminating it as a possible cause.
>>
>> Any further ideas as to what I can try? Is mdev a better choice?
>>
> Well mdev is at least easier to configure than udev.
>
> The only thing you must make sure in your init process is that /proc and
> /sys are mounted as early as possible (/etc/inittab is good place for that)
> and that echo /sbin/mdev > /proc/sys/kernel/hotplug is also somewhere
> in /etc/init.d/rcS (maybe at the start of that file)
>
> And check that you have etc/mdev.conf and etc/init.d/S10mdev (witch is
> called by /etc/init.d/rcS)
>
> This is what I would do (and have done with my live CD)
> Forget the buildroot way of making initramfs for now and see if you can
> construct live CD by hand:
>
> 1 ) make clean
>
> 2 ) make sure you have all the needed init stuff in fs/skeleton/etc
> directory (inittab, init.d/rcS, init.d/S* files etc.....)
> also make sure that sbin/init is a symlink to /bin/busybox
> (I have also symlink of init --> /bin/busybox in top of fs/skeleton but
> I not sure if that is stricly needed ...
> I think kernel should be looking from /sbin/init if no other init found)
>
> 3 ) do make menuconfig as you would normally but remember to unselect
> cpio, initramfs and iso9660 from menuconfig
> remember to select grub from under Bootloader section if you
> don't already have it
> don't select too much of stuff even if you have massive amounts
> of RAM in your test systems.
> reason being that you are making initramfs later here from your
> output/target directory and if you have massive
> amount's of stuff in there then it will take forever to boot. (I
> have managed to do live CD with massive amounts of stuff on it and
> booting fast with only 192 MB RAM but that needed some major hacking)
>
> 4 ) do make linux-menuconfig and check that under General setup the
> setting Initramfs source files is empty
> also check the compression support here that you want to use for
> your external initramfs (let's suppose its' the default GZ for now)
>
> 5 ) do make
>
> 6 ) after buildroot has finished make sure that everything is okay in
> your output/target (check especially boot/ etc/ and /dev directory)
> also make sure you have /boot/grub/menu.lst or /boot/grub/grub.conf
> (the other is usually just symlink to other) and check it's settings
> (If you are not familiar with grub then I can help with it's
> settings, especially important is the line where you tell grub the external
> initramfs file)
> remove the symlink (iso9660 format does not support symlinks)
>
> 7 ) Create directory where you want to put your kernel & bootloader
> (a.ka. the whole contents of /boot dir) and external initramfs file
> that is generated next:
>
> mkdir /livecd && cp -r output/target/boot /livecd
>
> 8 ) from output/target dir do find . -not \( -path "./boot" -prune
> \) -print0 | cpio --null -ov --format=newc | gzip -9 > /livecd/initramfs.gz
> (we don't need boot directory inside initramfs. it needs to stay outside
> of it. that why it was copied previously)
>
> 9 ) make iso9660 normally from the contents of your /livecd
> mkdir /livecd_output && cd /livecd && mkisofs --joliet -R -b
> boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4
> -boot-info-table -iso-level 4 -hide-rr-moved -c boot.catalog -o
> /livecd_output/your_livecd.iso .
>
> (remember that . at the end)
>
> 10) burn the iso to CD or even better use qemu or VirtualBox to boot
> your iso without wasting CD disc.
>
> If this manual way worked then next try buildroot way.
>
> Best regards
> Stefan
>
>> Thanks for your help,
>>
>> Antony
>>
>> ________________
>>
>> Macrium? Software is a trading name of Paramount Software UK Ltd,
>> Registered in England and Wales Number 02973414
>> Registered Office: Kilburn House, Manchester Science Park, Lloyd St.
>> North, Manchester M15 6SE United Kingdom
>>
>> The information contained in this e-mail is confidential, privileged,
>> or otherwise protected from disclosure. It is intended only for the
>> use of the authorized individual as indicated in the e-mail. Any
>> unauthorized disclosure, copying, distribution or taking of any action
>> based on the contents of this material is strictly prohibited.
>>
>> If you have received this e-mail in error, please delete it immediately.
>>
>>
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
--
Antony Vennard
Software Engineer
Macrium Software
Kilburn House,
Manchester Science Park
Lloyd Street North
Manchester M15 6SE
UK
Tel: +44(0)161 226 1128
Web http://www.macrium.com/
Blog http://blog.macrium.com/
Twitter http://twitter.com/MacriumReflect
Facebook http://www.facebook.com/Macrium
--
________________
Macrium? Software is a trading name of Paramount Software UK Ltd,
Registered in England and Wales Number 02973414
Registered Office: Kilburn House, Manchester Science Park, Lloyd St. North,
Manchester M15 6SE United Kingdom
The information contained in this e-mail is confidential, privileged, or
otherwise protected from disclosure. It is intended only for the use of the
authorized individual as indicated in the e-mail. Any unauthorized
disclosure, copying, distribution or taking of any action based on the
contents of this material is strictly prohibited.
If you have received this e-mail in error, please delete it immediately.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 895 bytes
Desc: OpenPGP digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121108/5730efff/attachment.asc>
^ permalink raw reply
* [Buildroot] [git commit] lcdproc: bump version to 0.5.6
From: Peter Korsgaard @ 2012-11-08 15:41 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=b8a304a9f9089bf03e3649582cee7ea96718e92f
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
| 19 -------------------
package/lcdproc/lcdproc.mk | 2 +-
2 files changed, 1 insertions(+), 20 deletions(-)
diff --git a/package/lcdproc/lcdproc-0.5.5-fix-menu-segfault.patch b/package/lcdproc/lcdproc-0.5.5-fix-menu-segfault.patch
deleted file mode 100644
index f0ebe2d..0000000
--- a/package/lcdproc/lcdproc-0.5.5-fix-menu-segfault.patch
+++ /dev/null
@@ -1,19 +0,0 @@
-Trying to add a menu item using menu_add_item causes a segmentation fault
-in the LCDd server. This is caused by a read beyond the end of an array.
-
-This patch adds a safety check on the size of the argument array.
-
-Signed-off-by: Simon Dawson <spdawson@gmail.com>
-
-diff -Nurp a/server/commands/menu_commands.c b/server/commands/menu_commands.c
---- a/server/commands/menu_commands.c 2011-08-14 13:29:16.000000000 +0100
-+++ b/server/commands/menu_commands.c 2012-10-04 22:19:07.997409193 +0100
-@@ -198,7 +198,7 @@ menu_add_item_func(Client *c, int argc,
-
- /* call menu_set_item() with a temporarily allocated argv
- * to process the remaining options */
-- if ((argc > 5) || (argv[4][0] == '-')) {
-+ if ((argc > 5) || ((argc == 5) && argv[4][0] == '-')) {
- // menu_add_item <menuid> <newitemid> <type> [<text>]
- // menu_set_item <menuid> <itemid> {<option>}+
- int i, j;
diff --git a/package/lcdproc/lcdproc.mk b/package/lcdproc/lcdproc.mk
index 7914c85..aa204f1 100644
--- a/package/lcdproc/lcdproc.mk
+++ b/package/lcdproc/lcdproc.mk
@@ -3,7 +3,7 @@
# lcdproc
#
#############################################################
-LCDPROC_VERSION = 0.5.5
+LCDPROC_VERSION = 0.5.6
LCDPROC_SOURCE = lcdproc-$(LCDPROC_VERSION).tar.gz
LCDPROC_SITE = http://downloads.sourceforge.net/project/lcdproc/lcdproc/$(LCDPROC_VERSION)
LCDPROC_LICENSE = GPLv2+
^ permalink raw reply related
* [Buildroot] [git commit] kmod: don't build documentation if not needed
From: Peter Korsgaard @ 2012-11-08 15:26 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=2fc64312d4840eb777df7e10b8405a364e813b9e
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
No sense in building it if we throw it away in target-finalize anyway.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/kmod/kmod.mk | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/package/kmod/kmod.mk b/package/kmod/kmod.mk
index c6ef6a1..2833629 100644
--- a/package/kmod/kmod.mk
+++ b/package/kmod/kmod.mk
@@ -4,6 +4,10 @@ KMOD_SITE = $(BR2_KERNEL_MIRROR)/linux/utils/kernel/kmod/
KMOD_INSTALL_STAGING = YES
KMOD_DEPENDENCIES = host-pkgconf
+ifneq ($(BR2_HAVE_DOCUMENTATION),y)
+KMOD_CONF_OPT += --disable-manpages
+endif
+
ifeq ($(BR2_PACKAGE_ZLIB),y)
KMOD_DEPENDENCIES += zlib
KMOD_CONF_OPT += --with-zlib
^ permalink raw reply related
* [Buildroot] Udev on a live CD system does not appear to populate /dev
From: Arnout Vandecappelle @ 2012-11-08 15:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CACpMmu9g8xXNsyQp6DheEqP9z_Q=7DwkorWc120-gW5wQj9+YA@mail.gmail.com>
On 11/08/12 10:56, Antony Vennard wrote:
> I'm not using initramfs - I'm using the ISO 9660 target which as far as I can see produces an initrd, a kernel and an
> ext2 raw image which it mounts as a ramdisk.
Right! I completely forgot that! The iso9660 target is currently broken
(and has been for quite some time already). For the time being, you have to
manually copy fs/cpio/init to the target (either copy it to $1/init in the
post-build script, or copy it to skeleton/init and do a clean build).
Or, you could modify fs/iso9660/iso9660.mk and Config.in to use a cpio
archive as rootfs instead of an ext2. If you do that and it works, please
post a patch for inclusion in buildroot, thanks!
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH v11 2/9] perl: new package
From: Arnout Vandecappelle @ 2012-11-08 15:04 UTC (permalink / raw)
To: buildroot
In-Reply-To: <h0de7k.bir.ln@bernd-kuhls.de>
On 11/07/12 20:32, Bernd Kuhls wrote:
> Arnout Vandecappelle<arnout@mind.be> wrote in
> news:50999637.1090305 at mind.be:
>
>>> maybe this can be of help: http://perlcross.berlios.de/
>>
>> That sounds like a terrific idea! Do you feel up to integrating this in
>> buildroot and sending a patch?
>
> Unfortunately not due to lack of skill :(
In that case, I'll try to take a look at it this evening.
We really need to get this perl mess fixed for the 2012.11 release...
(Francois, with that I don't want to imply that you did a bad job. On the
contrary, getting the build with qemu running was an important step even if
it will have to be replaced eventually.)
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] Autotest infrastructure
From: Arnout Vandecappelle @ 2012-11-08 15:00 UTC (permalink / raw)
To: buildroot
Thomas, all,
If we want more features in the autobuilders, it may be worthwhile to reuse
existing infrastructure. At ELC-E, I attended a talk about autotest
( http://github.com/autotest ) and I wrote a small report about that talk
( http://wp.me/pNMCz-2t ). It sounds like it could be something that can be
used for the autobuilders, though of course it won't work out of the box for
us...
Regards,
Arnout
--
Arnout Vandecappelle arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . +32-16-286540 . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43
^ permalink raw reply
* [Buildroot] problem building a SDL app with buildroot
From: Jeremy Rosen @ 2012-11-08 12:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHXCMMJjaafke3POAv04fdK80L_DWguu+UdbDrah9HSYPfwf-g@mail.gmail.com>
> > OUTPUT_VARIABLE SDL_CFLAGS)
>
> As a quick fix, in your app *.mk file, you can try to add:
> <your app prefix>_CONF_OPT +=
> -DSDL_CONFIG="$(STAGING_DIR)/usr/bin/sdl-config"
>
yup, I did that and it did fix my problem, thx... now i'm looking into some gettext problems, but that will be a seaparate email :)
> You don't have to change anything in the sdl-config from the staging
> area, it is already handled by the sdl package.
>
>
> BTW, that an issue we are aware of, and we talked a bit about it
> during the last Buildroot Dev Days.
> We just need some time to work on and figure out the best way to fix
> this.
>
>
fair enough, I wanted to make sure I didn't miss something obvious... the fix above is good enough for me until there is an official way of doing it
Regards
Jeremy
> Regards,
>
> --
> Sam
>
^ permalink raw reply
* [Buildroot] Udev on a live CD system does not appear to populate /dev
From: Stefan Fröberg @ 2012-11-08 12:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CACpMmu9g8xXNsyQp6DheEqP9z_Q=7DwkorWc120-gW5wQj9+YA@mail.gmail.com>
Hi Antony
Just one guestion: What bootloader are you using for your Live CD ?
(I use grub)
8.11.2012 11:56, Antony Vennard kirjoitti:
> Hi All,
>
> I'm not using initramfs - I'm using the ISO 9660 target which as far
> as I can see produces an initrd, a kernel and an ext2 raw image which
> it mounts as a ramdisk. If I select the initramfs options, the cpio
> filesystem is generated prior to the iso9660 one, *but the initramfs
> afterwards!* Which means, as far as I can see, that initramfs would
> not be placed on the disk - unless buildroot manipulates the iso
> filesystem post creation? I could of course mkisofs myself, but I was
> trying to avoid that - although if this fixes udev, I'll do it.
>
Keep in mind that the buildroot way of making initramfs (that is if you
select intramfs from menuconfig) is
to embed your initramfs directly into kernel.
There are three disadvantages in here:
1 ) It will make your kernel fatter
2 ) It will makes things more complicated than necessary
You might have two initramfs settings: One that is embedded directly
into your kernel and
another that you have made by hand by yourself. And it's very possible
that they could have conflicting stuff between them
You can have several initramfs files (at least with grub bootloader),
the last ones overlaying the first ones, in order.
3 ) It will makes less flexibe.
All kernels since 2.6 have initramfs inside them, it's just that by
default that environment is empty.
Embedding initramfs directly to kernel might be good for those users who
don't use any bootloader or are using a bootloader which can't
be feeded external, separate initramfs file(s) (like grub) and want to
have minimal system always available (as piggybacked inside kernel).
> I've nothing /dev related in my fs/skeleton, and only the default
> values in device_table.txt. Since I'm using udev, I did expect it
> would populate everything it needed in /dev - although unless I add
> entries for null, console and a tty into device_table.txt, I end up
> with a distribution that loops forever saying "could not find
> /dev/tty1" (if I've configured tty1 as the location for getty for
> example). I can't mitigate this by re-writing the inittab to launch
> getty "once" as opposed to respawn, since buildroot rewrites that -
> and askfirst:/bin/sh works, except that the respawn error messages are
> written all over /dev/console, making it unusable...!
>
> By the sounds of things this is wrong, but I'm currently attempting to
> preconfigure some devices in device_table.txt - e.g. /dev/null,
> /dev/urandom et al pseudo devices, and I'm borrowing Ubuntu's rules.d
> to see if these are any more effective than Fedora's. Leaving
> device_table.txt as its default causes the tty1 missing loop. I am not
> expecting this to work - I cannot see how udev rules differ greatly
> between distributions - just eliminating it as a possible cause.
>
> Any further ideas as to what I can try? Is mdev a better choice?
>
Well mdev is at least easier to configure than udev.
The only thing you must make sure in your init process is that /proc and
/sys are mounted as early as possible (/etc/inittab is good place for that)
and that echo /sbin/mdev > /proc/sys/kernel/hotplug is also somewhere
in /etc/init.d/rcS (maybe at the start of that file)
And check that you have etc/mdev.conf and etc/init.d/S10mdev (witch is
called by /etc/init.d/rcS)
This is what I would do (and have done with my live CD)
Forget the buildroot way of making initramfs for now and see if you can
construct live CD by hand:
1 ) make clean
2 ) make sure you have all the needed init stuff in fs/skeleton/etc
directory (inittab, init.d/rcS, init.d/S* files etc.....)
also make sure that sbin/init is a symlink to /bin/busybox
(I have also symlink of init --> /bin/busybox in top of fs/skeleton but
I not sure if that is stricly needed ...
I think kernel should be looking from /sbin/init if no other init found)
3 ) do make menuconfig as you would normally but remember to unselect
cpio, initramfs and iso9660 from menuconfig
remember to select grub from under Bootloader section if you
don't already have it
don't select too much of stuff even if you have massive amounts
of RAM in your test systems.
reason being that you are making initramfs later here from your
output/target directory and if you have massive
amount's of stuff in there then it will take forever to boot. (I
have managed to do live CD with massive amounts of stuff on it and
booting fast with only 192 MB RAM but that needed some major hacking)
4 ) do make linux-menuconfig and check that under General setup the
setting Initramfs source files is empty
also check the compression support here that you want to use for
your external initramfs (let's suppose its' the default GZ for now)
5 ) do make
6 ) after buildroot has finished make sure that everything is okay in
your output/target (check especially boot/ etc/ and /dev directory)
also make sure you have /boot/grub/menu.lst or /boot/grub/grub.conf
(the other is usually just symlink to other) and check it's settings
(If you are not familiar with grub then I can help with it's
settings, especially important is the line where you tell grub the external
initramfs file)
remove the symlink (iso9660 format does not support symlinks)
7 ) Create directory where you want to put your kernel & bootloader
(a.ka. the whole contents of /boot dir) and external initramfs file
that is generated next:
mkdir /livecd && cp -r output/target/boot /livecd
8 ) from output/target dir do find . -not \( -path "./boot" -prune
\) -print0 | cpio --null -ov --format=newc | gzip -9 > /livecd/initramfs.gz
(we don't need boot directory inside initramfs. it needs to stay outside
of it. that why it was copied previously)
9 ) make iso9660 normally from the contents of your /livecd
mkdir /livecd_output && cd /livecd && mkisofs --joliet -R -b
boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4
-boot-info-table -iso-level 4 -hide-rr-moved -c boot.catalog -o
/livecd_output/your_livecd.iso .
(remember that . at the end)
10) burn the iso to CD or even better use qemu or VirtualBox to boot
your iso without wasting CD disc.
If this manual way worked then next try buildroot way.
Best regards
Stefan
> Thanks for your help,
>
> Antony
>
> ________________
>
> Macrium^(TM) Software is a trading name of Paramount Software UK Ltd,
> Registered in England and Wales Number 02973414
> Registered Office: Kilburn House, Manchester Science Park, Lloyd St.
> North, Manchester M15 6SE United Kingdom
>
> The information contained in this e-mail is confidential, privileged,
> or otherwise protected from disclosure. It is intended only for the
> use of the authorized individual as indicated in the e-mail. Any
> unauthorized disclosure, copying, distribution or taking of any action
> based on the contents of this material is strictly prohibited.
>
> If you have received this e-mail in error, please delete it immediately.
>
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121108/d5fa34a3/attachment.html>
^ permalink raw reply
* [Buildroot] [PATCH v2] package: add bcusdk
From: Arnout Vandecappelle @ 2012-11-08 11:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509B8EF7.9090809@calao-systems.com>
On 11/08/12 11:52, Gr?gory Hermant wrote:
>>> >> + select BR2_PACKAGE_LIBPTHSEM
>> >
>> > ... and the architecture dependencies of libpthsem...
> Could you please enlighten me on this point ?
As I wrote in the review of libpthsem, pth doesn't work on a number
of the architectures we support. Since libpthsem is a fork of pth,
it's likely that it doesn't work in libpthsem either. Therefore, it
is likely that libpthsem requires some
depends on !BR2_microblaze && !BR2_...
which have to be inherited by the packages that select libpthsem.
(Thomas Petazzoni reported that pth doesn't work on arm-glibc, for
instance...).
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH v2] package: add bcusdk
From: Grégory Hermant @ 2012-11-08 10:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509B6EA8.3090605@mind.be>
Le 08/11/2012 09:34, Arnout Vandecappelle a ?crit :
>> diff --git a/package/bcusdk/Config.in b/package/bcusdk/Config.in
>> new file mode 100644
>> index 0000000..c7b1b95
>> --- /dev/null
>> +++ b/package/bcusdk/Config.in
>> @@ -0,0 +1,11 @@
>> +config BR2_PACKAGE_BCUSDK
>> + bool "bcusdk"
>> + depends on BR2_INSTALL_LIBSTDCPP
>> + select BR2_PACKAGE_LIBPTHSEM
>
> ... and the architecture dependencies of libpthsem...
Could you please enlighten me on this point ?
BR,
gregory
CALAO SYSTEMS <http://www.calao-systems.com/>
*CALAO SYSTEMS*
Le Magist?re II
334, rue des Vingt Toises
38950 Saint Martin le Vinoux
France
Phone : *+33 (0)4 76 56 38 05*
Fax : *+33 (0)4 76 56 38 06*
Cette communication (y compris les pi?ces jointes) est r?serv?e ? l'usage exclusif du destinataire (des destinataires) et peut contenir des informations privil?gi?es, confidentielles, exempt?es de
divulgation selon la loi ou prot?g?es par les droits d'auteur. Si vous n'?tes pas un destinataire, toute utilisation, divulgation, distribution, reproduction, examen ou copie (totale ou partielle) est
non-autoris?e et peut ?tre ill?gale. Tout message ?lectronique est susceptible d'alt?ration et son int?grit? ne peut ?tre assur?e. CALAO SYSTEMS d?cline toute responsabilit? au titre de ce message
s'il a ?t? modifi? ou falsifi?. Si vous n'?tes pas destinataire de ce message, merci de le d?truire imm?diatement et d'avertir l'exp?diteur de l'erreur de distribution et de la destruction du message.
Merci.
This transmission (including any attachments) is intended solely for the use of the addressee(s) and may contain confidential information including trade secrets which are privileged, confidential,
exempt from disclosure under applicable law and/or subject to copyright. If you are not an intended recipient, any use, disclosure, distribution, reproduction, review or copying (either whole or
partial) is unauthorized and may be unlawful. E-mails are susceptible to alteration and their integrity cannot be guaranteed. CALAO SYSTEMS shall not be liable for this e-mail if modified or
falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Thank you.
^ permalink raw reply
* [Buildroot] problem building a SDL app with buildroot
From: Samuel Martin @ 2012-11-08 10:49 UTC (permalink / raw)
To: buildroot
In-Reply-To: <ec166773-a3e8-47b9-be33-ea05a0cfccab@zimbra2.corp.accelance.fr>
Hi Jeremy,
2012/11/8 Jeremy Rosen <jeremy.rosen@openwide.fr>:
> Hello everybody
>
> I am trying to compile and package an app that is using the sdl library and I have a problem
>
> the program uses cmake as its build system and uses a small script called "sdl-config" to find the compile time parameters for sdl.
>
> that script is provided by the sdl library, and when grepping the output/ directory I can find it installed in
>
> output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/bin/sdl-config
>
> however cmake seems not to be able to find it... I am not sure if the sysroot directory should be added to the path, and if not how I am supposed to have sdl apps find their configureation (I can probably overrid the path to sdl-config for my particual app, but I am wondering if there isn't a more generic problem with the way sdl is installed in the cross-compile environement)
>
> relevent lines from the cmake configuration file :
>
> CMakeCache.txt:SDL_CONFIG:STRING=sdl-config
> CMakeLists.txt: set(SDL_CONFIG "sdl-config" CACHE STRING "Path to sdl-config script")
> CMakeLists.txt: exec_program(${SDL_CONFIG} ARGS "--cflags" OUTPUT_VARIABLE SDL_CFLAGS)
As a quick fix, in your app *.mk file, you can try to add:
<your app prefix>_CONF_OPT += -DSDL_CONFIG="$(STAGING_DIR)/usr/bin/sdl-config"
You don't have to change anything in the sdl-config from the staging
area, it is already handled by the sdl package.
BTW, that an issue we are aware of, and we talked a bit about it
during the last Buildroot Dev Days.
We just need some time to work on and figure out the best way to fix this.
Regards,
--
Sam
^ permalink raw reply
* [Buildroot] problem building a SDL app with buildroot
From: Jeremy Rosen @ 2012-11-08 10:21 UTC (permalink / raw)
To: buildroot
In-Reply-To: <18ba4b30-2ac3-44e7-ae59-5ca40d8137b3@zimbra2.corp.accelance.fr>
Hello everybody
I am trying to compile and package an app that is using the sdl library and I have a problem
the program uses cmake as its build system and uses a small script called "sdl-config" to find the compile time parameters for sdl.
that script is provided by the sdl library, and when grepping the output/ directory I can find it installed in
output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/bin/sdl-config
however cmake seems not to be able to find it... I am not sure if the sysroot directory should be added to the path, and if not how I am supposed to have sdl apps find their configureation (I can probably overrid the path to sdl-config for my particual app, but I am wondering if there isn't a more generic problem with the way sdl is installed in the cross-compile environement)
relevent lines from the cmake configuration file :
CMakeCache.txt:SDL_CONFIG:STRING=sdl-config
CMakeLists.txt: set(SDL_CONFIG "sdl-config" CACHE STRING "Path to sdl-config script")
CMakeLists.txt: exec_program(${SDL_CONFIG} ARGS "--cflags" OUTPUT_VARIABLE SDL_CFLAGS)
thx a lot for the insight
Jeremy
fight key loggers : write some perl using vim
^ permalink raw reply
* [Buildroot] [PATCH 1/2] kmod: bump to 11
From: Peter Korsgaard @ 2012-11-08 10:11 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352365799-27913-1-git-send-email-yegorslists@googlemail.com>
>>>>> "yegorslists" == yegorslists <yegorslists@googlemail.com> writes:
yegorslists> From: Yegor Yefremov <yegorslists@googlemail.com>
yegorslists> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Committed both, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit] lm-sensors: bump to 3.3.3
From: Peter Korsgaard @ 2012-11-08 10:11 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=8ab9660933b76e53e316e973cacdc1ae3655f3b5
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/lm-sensors/lm-sensors.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/lm-sensors/lm-sensors.mk b/package/lm-sensors/lm-sensors.mk
index ba183ec..34aa742 100644
--- a/package/lm-sensors/lm-sensors.mk
+++ b/package/lm-sensors/lm-sensors.mk
@@ -4,7 +4,7 @@
#
#############################################################
-LM_SENSORS_VERSION = 3.3.2
+LM_SENSORS_VERSION = 3.3.3
LM_SENSORS_SOURCE = lm_sensors-$(LM_SENSORS_VERSION).tar.bz2
LM_SENSORS_SITE = http://dl.lm-sensors.org/lm-sensors/releases
LM_SENSORS_INSTALL_STAGING = YES
^ permalink raw reply related
* [Buildroot] [git commit] kmod: bump to 11
From: Peter Korsgaard @ 2012-11-08 10:10 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=f4c0618b51c6b9a17d57364c621d6f279718a974
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/kmod/kmod.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/kmod/kmod.mk b/package/kmod/kmod.mk
index 10f70f5..c6ef6a1 100644
--- a/package/kmod/kmod.mk
+++ b/package/kmod/kmod.mk
@@ -1,4 +1,4 @@
-KMOD_VERSION = 10
+KMOD_VERSION = 11
KMOD_SOURCE = kmod-$(KMOD_VERSION).tar.xz
KMOD_SITE = $(BR2_KERNEL_MIRROR)/linux/utils/kernel/kmod/
KMOD_INSTALL_STAGING = YES
^ permalink raw reply related
* [Buildroot] [PATCH] add new package grantlee
From: Zoltan Gyarmati @ 2012-11-08 10:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1351715883-10799-1-git-send-email-mr.zoltan.gyarmati@gmail.com>
Hi,
are they any issues still with the the patch below? If not, what shall i
do to push it forward?
thx, best regards,
Zoltan Gyarmati
On 10/31/2012 09:38 PM, Zoltan Gyarmati mr.zoltan.gyarmati at gmail.com wrote:
> From: Zoltan Gyarmati <mr.zoltan.gyarmati@gmail.com>
>
>
> Signed-off-by: Zoltan Gyarmati <mr.zoltan.gyarmati@gmail.com>
> ---
> package/Config.in | 1 +
> package/grantlee/Config.in | 9 +++++++++
> package/grantlee/grantlee.mk | 13 +++++++++++++
> 3 files changed, 23 insertions(+)
> create mode 100644 package/grantlee/Config.in
> create mode 100644 package/grantlee/grantlee.mk
>
> diff --git a/package/Config.in b/package/Config.in
> index ab966e0..ef68b37 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -139,6 +139,7 @@ source "package/qt/Config.in"
> if BR2_PACKAGE_QT
> comment "QT libraries and helper libraries"
> source "package/qtuio/Config.in"
> +source "package/grantlee/Config.in"
> endif
>
> source "package/x11r7/Config.in"
> diff --git a/package/grantlee/Config.in b/package/grantlee/Config.in
> new file mode 100644
> index 0000000..84afad2
> --- /dev/null
> +++ b/package/grantlee/Config.in
> @@ -0,0 +1,9 @@
> +config BR2_PACKAGE_GRANTLEE
> + bool "grantlee"
> + select BR2_PACKAGE_QT_STL
> + select BR2_PACKAGE_QT_SCRIPT
> + select BR2_PACKAGE_QT_GUI_MODULE
> + help
> + Qt implemantation of the Django template framework
> +
> + http://www.grantlee.org
> diff --git a/package/grantlee/grantlee.mk b/package/grantlee/grantlee.mk
> new file mode 100644
> index 0000000..10adfd9
> --- /dev/null
> +++ b/package/grantlee/grantlee.mk
> @@ -0,0 +1,13 @@
> +#############################################################
> +#
> +# grantlee
> +#
> +#############################################################
> +
> +GRANTLEE_VERSION = 0.2.0
> +GRANTLEE_SITE = http://downloads.grantlee.org
> +GRANTLEE_INSTALL_STAGING = YES
> +GRANTLEE_DEPENDENCIES = qt
> +
> +$(eval $(cmake-package))
> +
^ permalink raw reply
* [Buildroot] Udev on a live CD system does not appear to populate /dev
From: Antony Vennard @ 2012-11-08 9:56 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509AA0C4.4060506@petroprogram.com>
Hi All,
I'm not using initramfs - I'm using the ISO 9660 target which as far as I
can see produces an initrd, a kernel and an ext2 raw image which it mounts
as a ramdisk. If I select the initramfs options, the cpio filesystem is
generated prior to the iso9660 one, but the initramfs afterwards! Which
means, as far as I can see, that initramfs would not be placed on the disk
- unless buildroot manipulates the iso filesystem post creation? I could of
course mkisofs myself, but I was trying to avoid that - although if this
fixes udev, I'll do it.
I've nothing /dev related in my fs/skeleton, and only the default values in
device_table.txt. Since I'm using udev, I did expect it would populate
everything it needed in /dev - although unless I add entries for null,
console and a tty into device_table.txt, I end up with a distribution that
loops forever saying "could not find /dev/tty1" (if I've configured tty1 as
the location for getty for example). I can't mitigate this by re-writing
the inittab to launch getty "once" as opposed to respawn, since buildroot
rewrites that - and askfirst:/bin/sh works, except that the respawn error
messages are written all over /dev/console, making it unusable...!
By the sounds of things this is wrong, but I'm currently attempting to
preconfigure some devices in device_table.txt - e.g. /dev/null,
/dev/urandom et al pseudo devices, and I'm borrowing Ubuntu's rules.d to
see if these are any more effective than Fedora's. Leaving device_table.txt
as its default causes the tty1 missing loop. I am not expecting this to
work - I cannot see how udev rules differ greatly between distributions -
just eliminating it as a possible cause.
Any further ideas as to what I can try? Is mdev a better choice?
Thanks for your help,
Antony
--
________________
Macrium(tm) Software is a trading name of Paramount Software UK Ltd,
Registered in England and Wales Number 02973414
Registered Office: Kilburn House, Manchester Science Park, Lloyd St. North,
Manchester M15 6SE United Kingdom
The information contained in this e-mail is confidential, privileged, or
otherwise protected from disclosure. It is intended only for the use of the
authorized individual as indicated in the e-mail. Any unauthorized
disclosure, copying, distribution or taking of any action based on the
contents of this material is strictly prohibited.
If you have received this e-mail in error, please delete it immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121108/af2cc0e5/attachment.html>
^ permalink raw reply
* [Buildroot] [PATCH 2/2] lm-sensors: bump to 3.3.3
From: yegorslists at googlemail.com @ 2012-11-08 9:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352365799-27913-1-git-send-email-yegorslists@googlemail.com>
From: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
package/lm-sensors/lm-sensors.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/lm-sensors/lm-sensors.mk b/package/lm-sensors/lm-sensors.mk
index ba183ec..34aa742 100644
--- a/package/lm-sensors/lm-sensors.mk
+++ b/package/lm-sensors/lm-sensors.mk
@@ -4,7 +4,7 @@
#
#############################################################
-LM_SENSORS_VERSION = 3.3.2
+LM_SENSORS_VERSION = 3.3.3
LM_SENSORS_SOURCE = lm_sensors-$(LM_SENSORS_VERSION).tar.bz2
LM_SENSORS_SITE = http://dl.lm-sensors.org/lm-sensors/releases
LM_SENSORS_INSTALL_STAGING = YES
--
1.7.7
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] kmod: bump to 11
From: yegorslists at googlemail.com @ 2012-11-08 9:09 UTC (permalink / raw)
To: buildroot
From: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
package/kmod/kmod.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/kmod/kmod.mk b/package/kmod/kmod.mk
index 10f70f5..c6ef6a1 100644
--- a/package/kmod/kmod.mk
+++ b/package/kmod/kmod.mk
@@ -1,4 +1,4 @@
-KMOD_VERSION = 10
+KMOD_VERSION = 11
KMOD_SOURCE = kmod-$(KMOD_VERSION).tar.xz
KMOD_SITE = $(BR2_KERNEL_MIRROR)/linux/utils/kernel/kmod/
KMOD_INSTALL_STAGING = YES
--
1.7.7
^ permalink raw reply related
* [Buildroot] [PATCH 3/6] Add firmware for the AW-NH580 connectivity module of the snowball
From: Grégory Hermant @ 2012-11-08 8:47 UTC (permalink / raw)
To: buildroot
In-Reply-To: <509055D9.3040805@mind.be>
Le 30/10/2012 23:34, Arnout Vandecappelle a ?crit :
>
>> +
>> diff --git a/package/snowball-firmware/snowball-firmware.mk b/package/snowball-firmware/snowball-firmware.mk
>> new file mode 100644
>> index 0000000..05326e2
>> --- /dev/null
>> +++ b/package/snowball-firmware/snowball-firmware.mk
>> @@ -0,0 +1,17 @@
>> +#############################################################
>> +#
>> +# snowball-firmware
>> +#
>> +#############################################################
>> +SNOWBALL_FIRMWARE_VERSION = 1.1.3-5
>> +SNOWBALL_FIRMWARE_SOURCE = ux500-firmware_$(SNOWBALL_FIRMWARE_VERSION).tar.gz
>> +SNOWBALL_FIRMWARE_SITE = https://launchpad.net/~linaro-maintainers/+archive/overlay/+files/
>> +SNOWBALL_FIRMWARE_LICENSE = PROPRIETARY
>
> Again not a very accurate license. "Snowball click-wrap license" is more
> appropriate. It does come pretty close to proprietary, however. I wonder
> if the linaro maintainers have permission to redistribute it via launchpad...
>
> The license file is license.txt.
What do you suggest for the UX500_FIRMWARE_LICENSE = ?
BR,
gregory
^ permalink raw reply
* [Buildroot] [PATCH v3 10/10] Make savedefconfig save to a configured file.
From: Arnout Vandecappelle @ 2012-11-08 8:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352363776-23638-1-git-send-email-arnout@mind.be>
From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
Store BR2_DEFCONFIG in .config, and use it to update the original input
defconfig file after updating the configuration. When a config is
created by using the BR2_DEFCONFIG=... option, this is saved in the
.config file; later runs of savedefconfig will update that same location.
It is also possible to configure this place in the interactive
configuration.
The BR2_DEFCONFIG value itself is not saved into the generated
defconfig, since Kconfig considers it at its default. This is
intentional, to avoid hard-coding an absolute path in the defconfig.
It will anyway be set again when the defconfig is used with the
'make BR2_DEFCONFIG=... defconfig' command.
As a side-effect of this change, the *config options have been moved out
of the BR2_HAVE_DOT_CONFIG condition. This doesn't make any functional
difference, because the .config is still not read for the *config targets.
However, the defconfig and savedefconfig targets do need to include
.config now, which makes them slightly slower.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Luca Ceresoli <luca@lucaceresoli.net>
---
v3: replaced foo_defconfig documentation with BR2_DEFCONFIG.
---
Config.in | 12 ++++++++++++
Makefile | 17 +++++++++++++----
docs/manual/customize-store.txt | 10 ++++++----
3 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/Config.in b/Config.in
index 68190a5..27afbd1 100644
--- a/Config.in
+++ b/Config.in
@@ -16,6 +16,18 @@ config BR2_HOSTARCH
source "arch/Config.in"
+config BR2_DEFCONFIG_FROM_ENV
+ string
+ option env="BR2_DEFCONFIG"
+
+config BR2_DEFCONFIG
+ string "Location to save buildroot config"
+ default BR2_DEFCONFIG_FROM_ENV if BR2_DEFCONFIG_FROM_ENV != ""
+ default "$(CONFIG_DIR)/defconfig"
+ help
+ When running 'make savedefconfig', the defconfig file will be saved
+ in this location.
+
menu "Build options"
menu "Commands"
diff --git a/Makefile b/Makefile
index 0e9ae92..a1b0742 100644
--- a/Makefile
+++ b/Makefile
@@ -56,7 +56,7 @@ DATE:=$(shell date +%Y%m%d)
export BR2_VERSION_FULL:=$(BR2_VERSION)$(shell $(TOPDIR)/support/scripts/setlocalversion)
noconfig_targets:=menuconfig nconfig gconfig xconfig config oldconfig randconfig \
- defconfig %_defconfig savedefconfig allyesconfig allnoconfig silentoldconfig release \
+ %_defconfig allyesconfig allnoconfig silentoldconfig release \
randpackageconfig allyespackageconfig allnopackageconfig \
source-check print-version
@@ -557,6 +557,8 @@ else # ifeq ($(BR2_HAVE_DOT_CONFIG),y)
all: menuconfig
+endif # ifeq ($(BR2_HAVE_DOT_CONFIG),y)
+
# configuration
# ---------------------------------------------------------------------------
@@ -567,7 +569,12 @@ $(BUILD_DIR)/buildroot-config/%onf:
mkdir -p $(@D)/lxdialog
$(MAKE) CC="$(HOSTCC_NOCCACHE)" HOSTCC="$(HOSTCC_NOCCACHE)" obj=$(@D) -C $(CONFIG) -f Makefile.br $(@F)
+DEFCONFIG = $(call qstrip,$(BR2_DEFCONFIG))
+
+# We don't want to fully expand BR2_DEFCONFIG here, so Kconfig will
+# recognize that if it's still at its default $(CONFIG_DIR)/defconfig
COMMON_CONFIG_ENV = \
+ BR2_DEFCONFIG='$(call qstrip,$(value BR2_DEFCONFIG))' \
KCONFIG_AUTOCONFIG=$(BUILD_DIR)/buildroot-config/auto.conf \
KCONFIG_AUTOHEADER=$(BUILD_DIR)/buildroot-config/autoconf.h \
KCONFIG_TRISTATE=$(BUILD_DIR)/buildroot-config/tristate.config \
@@ -639,7 +646,7 @@ silentoldconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
defconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
@mkdir -p $(BUILD_DIR)/buildroot-config
- @$(COMMON_CONFIG_ENV) $< --defconfig$(if $(BR2_DEFCONFIG),=$(BR2_DEFCONFIG)) $(CONFIG_CONFIG_IN)
+ @$(COMMON_CONFIG_ENV) $< --defconfig$(if $(DEFCONFIG),=$(DEFCONFIG)) $(CONFIG_CONFIG_IN)
%_defconfig: $(BUILD_DIR)/buildroot-config/conf $(TOPDIR)/configs/%_defconfig outputmakefile
@mkdir -p $(BUILD_DIR)/buildroot-config
@@ -647,13 +654,15 @@ defconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
@mkdir -p $(BUILD_DIR)/buildroot-config
- @$(COMMON_CONFIG_ENV) $< --savedefconfig=$(CONFIG_DIR)/defconfig $(CONFIG_CONFIG_IN)
+ @$(COMMON_CONFIG_ENV) $< \
+ --savedefconfig=$(if $(DEFCONFIG),$(DEFCONFIG),$(CONFIG_DIR)/defconfig) \
+ $(CONFIG_CONFIG_IN)
# check if download URLs are outdated
source-check:
$(MAKE) DL_MODE=SOURCE_CHECK $(EXTRAMAKEARGS) source
-endif # ifeq ($(BR2_HAVE_DOT_CONFIG),y)
+.PHONY: defconfig savedefconfig
#############################################################
#
diff --git a/docs/manual/customize-store.txt b/docs/manual/customize-store.txt
index e1bce3a..c175606 100644
--- a/docs/manual/customize-store.txt
+++ b/docs/manual/customize-store.txt
@@ -18,13 +18,15 @@ Buildroot configuration
^^^^^^^^^^^^^^^^^^^^^^^
For storing the buildroot configuration itself, buildroot offers the
-following command: +make savedefconfig+
+following command: +make savedefconfig+.
This strips the buildroot configuration down by removing configuration
options that are@their default value. The result is stored in a file
-called +defconfig+. Copy this file to +foo_defconfig+ in the +configs+
-directory. The configuration can then be rebuilt by running
-+make foo_defconfig+
+called +defconfig+. If you want to save it in another place, update set
+the +BR2_DEFCONFIG+ option, or call make with +make savedefconfig
+BR2_DEFCONFIG=<path-to-defconfig>+. The usual place is
++configs/<boardname>_defconfig+. The configuration can then be rebuilt by
+running +make <boardname>_defconfig+.
Alternatively, you can copy the file to any other place and rebuild with
+make defconfig BR2_DEFCONFIG=<path-to-defconfig-file>+.
--
1.7.10.4
^ permalink raw reply related
* [Buildroot] [PATCH v3 09/10] uClibc: update-all-configs shouldn't update default uClibc config
From: Arnout Vandecappelle @ 2012-11-08 8:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352363776-23638-1-git-send-email-arnout@mind.be>
From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
The new update-all-configs starget will update the uClibc config file
if BR2_UCLIBC_CONFIG is set, even if it is set to the default value
in toolchain/uClibc/uClibc-xxx.config.
To avoid this, set the default BR2_UCLIBC_CONFIG to empty, and select
a default to use in the .mk file.
Note that uclibc-update-config will still overwrite the default file
in toolchain/uClibc/uClibc-xxx.config - presumably it's intentional.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Luca Ceresoli <luca@lucaceresoli.net>
---
v3: update-all-config -> update-all-configs
---
toolchain/uClibc/Config.in | 7 ++-----
toolchain/uClibc/uclibc.mk | 23 +++++++++++------------
2 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/toolchain/uClibc/Config.in b/toolchain/uClibc/Config.in
index f46a415..9cce05d 100644
--- a/toolchain/uClibc/Config.in
+++ b/toolchain/uClibc/Config.in
@@ -42,15 +42,12 @@ config BR2_UCLIBC_VERSION_STRING
config BR2_UCLIBC_CONFIG
string "uClibc configuration file to use?"
- default "toolchain/uClibc/uClibc-0.9.31.config" if BR2_UCLIBC_VERSION_0_9_31
- default "toolchain/uClibc/uClibc-0.9.32.config" if BR2_UCLIBC_VERSION_0_9_32
- default "toolchain/uClibc/uClibc-0.9.33.config" if BR2_UCLIBC_VERSION_0_9_33
- default "toolchain/uClibc/uClibc-snapshot.config" if BR2_UCLIBC_VERSION_SNAPSHOT
+ default ""
help
Some people may wish to use their own modified uClibc configuration
file and will specify their config file location with this option.
See also docs/README in this package.
- If unsure, use the default.
+ If left empty, a default configuration will be used.
config BR2_PTHREAD_DEBUG
bool "Thread library debugging"
diff --git a/toolchain/uClibc/uclibc.mk b/toolchain/uClibc/uclibc.mk
index c6ee491..634966f 100644
--- a/toolchain/uClibc/uclibc.mk
+++ b/toolchain/uClibc/uclibc.mk
@@ -6,22 +6,21 @@
ifeq ($(BR2_TOOLCHAIN_BUILDROOT),y)
-# specifying UCLIBC_CONFIG_FILE on the command-line overrides the .config
-# setting.
-ifndef UCLIBC_CONFIG_FILE
-UCLIBC_CONFIG_FILE=$(call qstrip,$(BR2_UCLIBC_CONFIG))
-endif
-
-UCLIBC_VERSION:=$(call qstrip,$(BR2_UCLIBC_VERSION_STRING))
+UCLIBC_VERSION = $(call qstrip,$(BR2_UCLIBC_VERSION_STRING))
ifeq ($(BR2_UCLIBC_VERSION_SNAPSHOT),y)
-UCLIBC_SITE:=http://www.uclibc.org/downloads/snapshots
-UCLIBC_DIR:=$(TOOLCHAIN_DIR)/uClibc
+UCLIBC_SITE = http://www.uclibc.org/downloads/snapshots
+UCLIBC_DIR = $(TOOLCHAIN_DIR)/uClibc
+UCLIBC_CONFIG_VERSION = snapshot
else
-UCLIBC_SITE:=http://www.uclibc.org/downloads
-UCLIBC_DIR:=$(TOOLCHAIN_DIR)/uClibc-$(UCLIBC_VERSION)
+UCLIBC_SITE = http://www.uclibc.org/downloads
+UCLIBC_DIR = $(TOOLCHAIN_DIR)/uClibc-$(UCLIBC_VERSION)
+UCLIBC_CONFIG_VERSION = $(subst $(space),.,$(wordlist 1,3,$(subst .,$(space),$(UCLIBC_VERSION))))
endif
+UCLIBC_CONFIG = $(call qstrip,$(BR2_UCLIBC_CONFIG))
+UCLIBC_CONFIG_FILE = $(or $(wildcard $(UCLIBC_CONFIG)),toolchain/uClibc/uClibc-$(UCLIBC_CONFIG_VERSION).config)
+
UCLIBC_PATCH_DIR:=toolchain/uClibc/
UCLIBC_SOURCE:=uClibc-$(UCLIBC_VERSION).tar.bz2
@@ -508,7 +507,7 @@ uclibc-oldconfig: $(UCLIBC_DIR)/.oldconfig
uclibc-update-config: uclibc-config
cp -f $(UCLIBC_DIR)/.config $(UCLIBC_CONFIG_FILE)
-ifneq ($(UCLIBC_CONFIG_FILE),)
+ifneq ($(UCLIBC_CONFIG),)
UPDATE_ALL_CONFIGS_TARGETS += uclibc-update-config
endif
--
1.7.10.4
^ permalink raw reply related
* [Buildroot] [PATCH v3 08/10] crosstool-ng: update-all-configs shouldn't update default crosstool-ng config
From: Arnout Vandecappelle @ 2012-11-08 8:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352363776-23638-1-git-send-email-arnout@mind.be>
From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
The new update-all-configs target will update the ctng config file
if BR2_TOOLCHAIN_CTNG_CONFIG is set, even if it is set to the
default value in toolchain/toolchain-crosstool-ng/crosstool-ng.config-xxx
To avoid this, set the default BR2_TOOLCHAIN_CTNG_CONFIG to empty,
and select a default to use in the .mk file.
Note that ctng-update-config will still overwrite the default
file in toolchain/toolchain-crosstool-ng/crosstool-ng.config-xxx -
presumably it's intentional.
Also factored out the often-qstripped BR2_TOOLCHAIN_CTNG_LIBC (thereby
adding a few missing qstrips).
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Luca Ceresoli <luca@lucaceresoli.net>
---
v2: fix copy-paste error in commit message (Samuel Martin)
---
toolchain/toolchain-crosstool-ng/Config.in | 6 ++----
toolchain/toolchain-crosstool-ng/crosstool-ng.mk | 16 +++++++++-------
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/toolchain/toolchain-crosstool-ng/Config.in b/toolchain/toolchain-crosstool-ng/Config.in
index 9cd5ca5..e55b206 100644
--- a/toolchain/toolchain-crosstool-ng/Config.in
+++ b/toolchain/toolchain-crosstool-ng/Config.in
@@ -40,15 +40,13 @@ config BR2_TOOLCHAIN_CTNG_LIBC
config BR2_TOOLCHAIN_CTNG_CONFIG
string "crosstool-NG configuration file to use"
- default "toolchain/toolchain-crosstool-ng/crosstool-ng.config-uClibc" if BR2_TOOLCHAIN_CTNG_uClibc
- default "toolchain/toolchain-crosstool-ng/crosstool-ng.config-eglibc" if BR2_TOOLCHAIN_CTNG_eglibc
- default "toolchain/toolchain-crosstool-ng/crosstool-ng.config-glibc" if BR2_TOOLCHAIN_CTNG_glibc
+ default ""
help
Enter here the crosstool-NG's .config file to use.
To fine-tune your toolchain, you can also call:
make ctng-menuconfig
- If unsure, keep the default value.
+ If left empty, a default configuration file is used.
if BR2_TOOLCHAIN_CTNG_uClibc
diff --git a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
index f8dc88a..4b1faca 100644
--- a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
+++ b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
@@ -9,9 +9,11 @@
# Internal variables
CTNG_DIR := $(BUILD_DIR)/build-toolchain
+CTNG_LIBC = $(call qstrip,$(BR2_TOOLCHAIN_CTNG_LIBC))
CTNG_UCLIBC_CONFIG_FILE := $(TOPDIR)/toolchain/uClibc/uClibc-0.9.33.config
-CTNG_CONFIG_FILE:=$(call qstrip,$(BR2_TOOLCHAIN_CTNG_CONFIG))
+CTNG_CONFIG = $(call qstrip,$(BR2_TOOLCHAIN_CTNG_CONFIG))
+CTNG_CONFIG_FILE = $(or $(wildcard $(CTNG_CONFIG)),toolchain/toolchain-crosstool-ng/crosstool-ng.config-$(CTNG_LIBC))
# Hack! ct-ng is in fact a Makefile script. As such, it accepts all
# make options, such as -C, which makes it uneeded to chdir prior
@@ -50,7 +52,7 @@ CTNG_LIBS_eglibc := $(CTNG_LIBS_glibc)
#--------------
# All that we need in /lib
-CTNG_LIBS_LIB += $(CTNG_LIBS_$(call qstrip,$(BR2_TOOLCHAIN_CTNG_LIBC)))
+CTNG_LIBS_LIB += $(CTNG_LIBS_$(CTNG_LIBC))
#--------------
# All that we need in /usr/lib
@@ -348,7 +350,7 @@ define ctng-oldconfig
$(call ctng,CT_IS_A_BACKEND=y \
CT_BACKEND_ARCH=$(CTNG_ARCH) \
CT_BACKEND_KERNEL=linux \
- CT_BACKEND_LIBC=$(BR2_TOOLCHAIN_CTNG_LIBC) \
+ CT_BACKEND_LIBC=$(CTNG_LIBC) \
oldconfig )
$(call ctng-fix-dot-config,$(1),$(CTNG_FIX_DOT_CONFIG_PATHS_SED))
endef
@@ -372,9 +374,9 @@ $(CTNG_DIR)/.config: $(CTNG_CONFIG_FILE) $(CONFIG_DIR)/.config
$(Q)if [ ! -f $@ ]; then \
mkdir -p "$(CTNG_DIR)"; \
libc="$$(awk -F '"' '$$1=="CT_LIBC=" { print $$2; }' "$<")"; \
- if [ "$${libc}" != "$(BR2_TOOLCHAIN_CTNG_LIBC)" ]; then \
+ if [ "$${libc}" != "$(CTNG_LIBC)" ]; then \
echo "* Inconsistency in crosstool-NG config file '$<'"; \
- echo "* - buildroot configured for '$(BR2_TOOLCHAIN_CTNG_LIBC)'"; \
+ echo "* - buildroot configured for '$(CTNG_LIBC)'"; \
echo "* - given config file for '$${libc}'"; \
exit 1; \
fi; \
@@ -392,7 +394,7 @@ ctng-menuconfig: $(CTNG_DIR)/.config
$(Q)$(call ctng,CT_IS_A_BACKEND=y \
CT_BACKEND_ARCH=$(CTNG_ARCH) \
CT_BACKEND_KERNEL=linux \
- CT_BACKEND_LIBC=$(BR2_TOOLCHAIN_CTNG_LIBC) \
+ CT_BACKEND_LIBC=$(CTNG_LIBC) \
menuconfig )
$(call ctng-oldconfig,$<)
$(call ctng-check-config-changed,$<,$<.timestamp)
@@ -401,6 +403,6 @@ ctng-menuconfig: $(CTNG_DIR)/.config
ctng-update-config: $(CTNG_DIR)/.config
cp -f $< $(CTNG_CONFIG_FILE)
-ifneq ($(CTNG_CONFIG_FILE),)
+ifneq ($(CTNG_CONFIG),)
UPDATE_ALL_CONFIGS_TARGETS += ctng-update-config
endif
--
1.7.10.4
^ 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