* [Buildroot] [PATCH 1/1] libmbus : bump version to 0.8
From: Sagaert Johan @ 2012-11-06 1:20 UTC (permalink / raw)
To: buildroot
This release contains many improvements bug fixes, and major new features and
support for float point numbers and support for multi-telegram communication...
Signed-off-by: Sagaert Johan <sagaert.johan@skynet.be>
---
package/libmbus/libmbus-bcopy.patch | 16 ----------------
package/libmbus/libmbus.mk | 2 +-
2 files changed, 1 insertion(+), 17 deletions(-)
delete mode 100644 package/libmbus/libmbus-bcopy.patch
diff --git a/package/libmbus/libmbus-bcopy.patch b/package/libmbus/libmbus-bcopy.patch
deleted file mode 100644
index 660cc37..0000000
--- a/package/libmbus/libmbus-bcopy.patch
+++ /dev/null
@@ -1,16 +0,0 @@
-Drop bcopy since it's deprecated.
-
-Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
-
-diff -Nura libmbus-0.7.0/mbus/mbus-tcp.c libmbus-0.7.0-bcopy/mbus/mbus-tcp.c
---- libmbus-0.7.0/mbus/mbus-tcp.c 2011-12-08 13:21:19.000000000 -0300
-+++ libmbus-0.7.0-bcopy/mbus/mbus-tcp.c 2012-05-03 09:08:36.987106612 -0300
-@@ -78,7 +78,7 @@
- return NULL;
- }
-
-- bcopy((void *)(host_addr->h_addr), (void *)(&s.sin_addr), host_addr->h_length);
-+ memmove((void *)(&s.sin_addr), (void *)(host_addr->h_addr), host_addr->h_length);
-
- if (connect(handle->sock, (struct sockaddr *)&s, sizeof(s)) < 0)
- {
diff --git a/package/libmbus/libmbus.mk b/package/libmbus/libmbus.mk
index 16e9e6a..9f25a3a 100644
--- a/package/libmbus/libmbus.mk
+++ b/package/libmbus/libmbus.mk
@@ -4,7 +4,7 @@
#
#############################################################
-LIBMBUS_VERSION = 0.7.0
+LIBMBUS_VERSION = 0.8.0
LIBMBUS_SITE = http://www.freescada.com/public-dist
LIBMBUS_INSTALL_STAGING = YES
--
1.8.0
^ permalink raw reply related
* [Buildroot] [PATCH v11 2/9] perl: new package
From: Arnout Vandecappelle @ 2012-11-06 1:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAB0FRsvaWPoSfSOv1uyPjpzHMU4a_hxPF_jB4XEhuVUFg4KcSQ@mail.gmail.com>
On 11/05/12 17:41, Fran?ois Perrad wrote:
>> > $/home/bernd/.fbr/build/output/build/perl-5.16.1/Cross/run-qemu-i386
>> > /home/bernd/.fbr/build/output/host/usr/bin/make all PERL_CORE=1
>> > LIBPERL_A=libperl.so
>> > qemu: Unsupported syscall: 240
>> > qemu: Unsupported syscall: 240
>> >
>> > First I got this error message with Debian Squeeze i386 (virtualbox guest,
>> > Win XP host), but also on Debian wheezy amd64 running non-virtualized.
>> >
>> > My .config can be found here:http://pastebin.com/yz1SzeB2
>> > I am using buildroot as part of the FLI4L source package[1].
>> >
>> > Kind regards, Bernd
>> >
> I could reproduce the lastest problem on the HEAD of Buildroot with
> qemu_x86_defconfig (which is a smaller config than your FLI4L config).
Is it possible that this is because the target binary is created with
kernel headers 3.2, but you're running it on a host which is only 2.6.32
(squeeze)? But then it should work on wheezy, because that has 3.2 as
well (at least since about four months IIRC). Although... 240 on i386
is futex, which has existed already since long before 2.6.32.
I do find this bug report:
https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/758424
but I'm not sure if it is relevant.
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] [PATCHv3] QtSerialPort: new package
From: Arnout Vandecappelle @ 2012-11-06 0:49 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAExDhvZaPz1pJSdrY1hWAMXV15Wp6LAtJb6y0Qbpn26YQtYQoQ@mail.gmail.com>
On 11/05/12 14:37, Thiago A. Corr?a wrote:
>> > Thiago> +define QTSERIALPORT_INSTALL_STAGING_CMDS
>> > Thiago> + $(MAKE) -C $(@D)/src install
>> > Thiago> + mv $(HOST_DIR)/usr/include/QtAddOnSerialPort $(STAGING_DIR)/usr/include/
>> >
>> > That seems funky. Why is it installing under HOST_DIR in the first
>> > place?
> Beats me:(
> The makefile generated by qmake is installing them there. Haven't
> found a better way to fix that so far.
Yikes!
./host/usr/bin/qmake -query
QT_INSTALL_PREFIX:/home/arnout/src/buildroot/output/host/usr
QT_INSTALL_DATA:/home/arnout/src/buildroot/output/host/usr
QT_INSTALL_DOCS:/home/arnout/src/buildroot/output/host/usr/doc
QT_INSTALL_HEADERS:/home/arnout/src/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/include
QT_INSTALL_LIBS:/home/arnout/src/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib
QT_INSTALL_BINS:/home/arnout/src/buildroot/output/host/usr/bin
QT_INSTALL_PLUGINS:/home/arnout/src/buildroot/output/host/usr/plugins
QT_INSTALL_IMPORTS:/home/arnout/src/buildroot/output/host/usr/imports
QT_INSTALL_TRANSLATIONS:/home/arnout/src/buildroot/output/host/usr/translations
QT_INSTALL_CONFIGURATION:/home/arnout/src/buildroot/output/host/usr
QT_INSTALL_EXAMPLES:/home/arnout/src/buildroot/output/host/usr
QT_INSTALL_DEMOS:/home/arnout/src/buildroot/output/host/usr
QMAKE_MKSPECS:/home/arnout/src/buildroot/output/host/usr/mkspecs
QMAKE_VERSION:2.01a
QT_VERSION:4.8.3
This is because we install qmake in $(HOST_DIR) and use a qt.conf to make
the paths point back to staging, but only for headers and libraries. Thomas,
do you remember why you didn't do that for prefix and data? (qt.mk:569-573,
introduced by ca290e7e).
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] add new package fxload
From: Arnout Vandecappelle @ 2012-11-06 0:01 UTC (permalink / raw)
To: buildroot
In-Reply-To: <30360444.162.1352137687822.JavaMail.rosen@pcrosen>
On 11/05/12 18:48, Jeremy Rosen wrote:
> Hello everybody
>
> I recently had to add a small utility called fxload to buildroot
>
> fxload is provided by the linux-hotplug project and is used to upload firmware into usb device
> it is generally used as a helper function by udev.
>
> This is my first patch to buildroot, so feel free to tell me if I didn't follow the proper protocol, I will gladly correct and resubmit
Here goes...
First of all, we prefer the patches to be sent in-line rather than as
attachment. That makes it easier to review by just replying to the mail.
git send-email is the easiest way to contribute.
Also I'll warn you: it may take a while (months) before your patch is
accepted even if you make all necessary correction, and we may even forget
to include it in the end. That's not because we're evil :-) but because
our contribution process is still sub-optimal. Buildroot has grown
significantly in number of contributions over the last two years, and
our maintainer (Peter Korsgaard) is just saturated. We're still experimenting
with ways to improve the process.
>
> Regards
> J?r?my Rosen
>
>
>
> fight key loggers : write some perl using vim
>
>
>
> 0001-add-new-package-fxload.patch
>
>
> From a1d3bdcf48851dedeca9597816135f4c1589e37a Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Rosen?=<jeremy.rosen@openwide.fr>
> Date: Fri, 2 Nov 2012 11:43:42 +0100
> Subject: [PATCH] add new package fxload
Add a Signed-off-by line for yourself. This is a short way for you to
assert that you are entitled to contribute the patch under buildroot's
GPL license. See http://kerneltrap.org/files/Jeremy/DCO.txt for more
details.
BTW, if you want to add additional comments that aren't supposed to
go in the git log message (e.g. "this is my first patch, please give
feedback", add it below the Signed-off-by line, separated by ---.
Then git-am will remove that part automatically. If you send an
updated patch, it's nice if you can write in this comment section what
changed compared to the first one. So typically you'll see:
Signed-off-by: ...
---
v2: Incorporated comments from Arnout, except for the foo because blah.
>
> ---
> package/Config.in | 1 +
> package/fxload/Config.in | 9 +++++++++
> package/fxload/fxload.mk | 20 ++++++++++++++++++++
> 3 files changed, 30 insertions(+)
> create mode 100644 package/fxload/Config.in
> create mode 100644 package/fxload/fxload.mk
>
> diff --git a/package/Config.in b/package/Config.in
> index 1df099b..f72a34b 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -211,6 +211,7 @@ source "package/flashrom/Config.in"
> source "package/fconfig/Config.in"
> source "package/fis/Config.in"
> source "package/fmtools/Config.in"
> +source "package/fxload/Config.in"
> source "package/gadgetfs-test/Config.in"
> source "package/gdisk/Config.in"
> source "package/gpsd/Config.in"
> diff --git a/package/fxload/Config.in b/package/fxload/Config.in
> new file mode 100644
> index 0000000..6fc28a7
> --- /dev/null
> +++ b/package/fxload/Config.in
> @@ -0,0 +1,9 @@
> +config BR2_PACKAGE_FXLOAD
> + bool "fxload"
> + help
This should be indented with a single tab.
> + This program is conveniently able to download firmware into FX, FX2,
> + and FX2LP EZ-USB devices, as well as the original AnchorChips EZ-USB.
> + It is intended to be invoked by hotplug scripts when the unprogrammed
> + device appears on the bus.
> +
> +http://sourceforge.net/projects/linux-hotplug/
The URL should be indented like the rest of the help text: 1 tab + 2 spaces.
> diff --git a/package/fxload/fxload.mk b/package/fxload/fxload.mk
> new file mode 100644
> index 0000000..a9c0249
> --- /dev/null
> +++ b/package/fxload/fxload.mk
> @@ -0,0 +1,20 @@
> +
That empty line shouldn't be there.
> +#############################################################
> +#
> +# fxload
> +#
> +#############################################################
> +FXLOAD_VERSION = 2008_10_13
> +FXLOAD_SOURCE = fxload-$(FXLOAD_VERSION).tar.gz
Since that is the default, we don't write that line.
> +FXLOAD_SITE =http://sourceforge.net/projects/linux-hotplug/files/fxload/$(FXLOAD_VERSION)
sf.net URLs are normally
http://downloads.sourceforge.net/project/linux-hotplug/fxload/$(FXLOAD_VERSION)
Maybe yours works as well, but it's nice to have the same pattern everywhere.
> +FXLOAD_LICENSE = GPLV2+
It's GPLv2+ (small v).
Also set FXLOAD_LICENSE_FILE = COPYING
> +
> +define FXLOAD_BUILD_CMDS
> + $(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_LD)" -C $(@D) all
For new packages, we try to consistently use
$(TARGET_MAKE_ENV) $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(@D) all
but that doesn't always work... If it doesn't, your pattern
is OK.
> +endef
> +
> +define FXLOAD_INSTALL_TARGET_CMDS
> + $(MAKE) prefix=$(TARGET_DIR) -C $(@D) install
We try to call make in exactly the same way in the install commands,
so that if for whatever reason something is still compiled there, it
will be compiled correctly.
Overall, it looks very good, though. Congratulations!
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] BR2_PREFER_STATIC_LIB and LDFLAGS+= -static
From: Arnout Vandecappelle @ 2012-11-05 23:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <F9C551623D2CBB4C9488801D14F864C628A986@ex-mb1.corp.adtran.com>
On 11/05/12 17:55, ANDY KENNEDY wrote:
> The following changes LDFLAGS from += -static to += --static if building
> with BR2_PREFER_STATIC_LIB so that various components actually build
> statically.
>
> Signed-off-by: Andy Kennedy<andy.kennedy@adtran.com>
Although I'm OK with this patch, I have been unable to reproduce the problem
and I'd like to know why it is going wrong with -static. Can you post a
defconfig that I can rebuild and that exposes the problem?
Note: a few autobuilders with BR2_PREFER_STATIC_LIB enabled could be nice -
or maybe not, because many packages _will_break.
Regards,
Arnout
> ---
> diff -Naur a/package/Makefile.in b/package/Makefile.in
> --- a/package/Makefile.in 2012-08-31 03:49:41.000000000 -0500
> +++ b/package/Makefile.in 2012-11-05 10:45:45.000000000 -0600
> @@ -299,7 +299,7 @@
>
> ifeq ($(BR2_PREFER_STATIC_LIB),y)
> SHARED_STATIC_LIBS_OPTS=--enable-static --disable-shared
> -TARGET_LDFLAGS += -static
> +TARGET_LDFLAGS += --static
> else
> SHARED_STATIC_LIBS_OPTS=--enable-static --enable-shared
> endif
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
--
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] Build root local site method
From: Arnout Vandecappelle @ 2012-11-05 23:23 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CADfuMF4YnAPm_m6YbjO0oCYPJKxqgGwX9amz7SOXhRB3x3mewg@mail.gmail.com>
On 11/05/12 13:41, Vasanth Ragavendran wrote:
> Hi
>
> This is with reference to the download method which is specified while compiling a new package. I'm writing certain
> programs which needs to be cross compiled and run in my embedded board. In my <pkg>.mk file I'm specifying the 'site' to
> the directory containing my source code and the 'site_method' to "local". I've made necessary changes to the Config.in
> files in all locations. I am able to select this package of mine from the menuconfig, however the package refuses to
> build for some unknown reason neither does the build print any errors. It just quietly skips compiling this package and
> finishes generating the file system. And the location which I'm pointing to in the mk file contains the necessary source
> code. I'm wondering what step I've skipped. Attaching the Config.in and <pkg>.mk file which I've created for my package.
> Kindly help as I'm struck in this and unable to proceed. I've referred to the manual but unable to solve this issue.
FTPCLIENT_INSTALL_TARGET should be YES, in capitals, else it will NOT install.
(Actually, YES is the default so you can just remove that line).
Maybe we should check that _INSTALL_TARGET etc. are either YES or NO. But
I'm afraid that will make an empty make much slower again... So maybe there
should be a 'make ftpclient-wtf-is-wrong-with-it' that does the checks :-)
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] add new package fxload
From: Jeremy Rosen @ 2012-11-05 17:48 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1781554.153.1352137532474.JavaMail.rosen@pcrosen>
Hello everybody
I recently had to add a small utility called fxload to buildroot
fxload is provided by the linux-hotplug project and is used to upload firmware into usb device
it is generally used as a helper function by udev.
This is my first patch to buildroot, so feel free to tell me if I didn't follow the proper protocol, I will gladly correct and resubmit
Regards
J?r?my Rosen
fight key loggers : write some perl using vim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-new-package-fxload.patch
Type: text/x-patch
Size: 2207 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121105/ea1fa413/attachment-0001.bin>
^ permalink raw reply
* [Buildroot] [PATCH] BR2_PREFER_STATIC_LIB and LDFLAGS+= -static
From: ANDY KENNEDY @ 2012-11-05 16:55 UTC (permalink / raw)
To: buildroot
The following changes LDFLAGS from += -static to += --static if building
with BR2_PREFER_STATIC_LIB so that various components actually build
statically.
Signed-off-by: Andy Kennedy <andy.kennedy@adtran.com>
---
diff -Naur a/package/Makefile.in b/package/Makefile.in
--- a/package/Makefile.in 2012-08-31 03:49:41.000000000 -0500
+++ b/package/Makefile.in 2012-11-05 10:45:45.000000000 -0600
@@ -299,7 +299,7 @@
ifeq ($(BR2_PREFER_STATIC_LIB),y)
SHARED_STATIC_LIBS_OPTS=--enable-static --disable-shared
-TARGET_LDFLAGS += -static
+TARGET_LDFLAGS += --static
else
SHARED_STATIC_LIBS_OPTS=--enable-static --enable-shared
endif
^ permalink raw reply
* [Buildroot] [PATCH v11 2/9] perl: new package
From: François Perrad @ 2012-11-05 16:41 UTC (permalink / raw)
To: buildroot
In-Reply-To: <upcp6k.3q9.ln@bernd-kuhls.de>
2012/10/30 Bernd Kuhls <berndkuhls@hotmail.com>:
> Hi,
>
> Francois Perrad <fperrad@gmail.com> wrote in
> news:1350652434-32020-2-git-send-email-francois.perrad at gadz.org:
>
> currently I am testing your patchset, but I found problems during
> compiling, some I could solve myself:
>
>> +PERL_CONF_OPT = -des \
>
> [...]
>
>> + -Dlibc=$(STAGING_DIR)/lib/libc.so \
>
> I had to change this line to
>
> -Dlibc=$(STAGING_DIR)/usr/lib/libc.so.0 \
>
> for usage with uClibc 0.9.33.2
>
> [...]
>
>> + -Uoptimize
>
> Here I had to add "-Ud_eaccess" to avoid a compilation bug.
>
> Perl will still not finish to compile, stopping with this error message:
>
>> LD_LIBRARY_PATH=/home/bernd/.fbr/build/output/build/perl-5.16.1
> /home/bernd/.fbr/build/output/build/perl-5.16.1/Cross/run-qemu-i386
> ./miniperl -Ilib make_ext.pl cpan/Archive-Extract/pm_to_blib
> MAKE=/home/bernd/.fbr/build/output/host/usr/bin/make LIBPERL_A=libperl.so
>> Making Archive::Extract (all)
>>
>> Creating Makefile.PL in cpan/Archive-Extract for Archive::Extract
>>
>> Running Makefile.PL in cpan/Archive-Extract
>> /home/bernd/.fbr/build/output/build/perl-5.16.1/Cross/run-qemu-i386
> ../../miniperl -I../../lib Makefile.PL INSTALLDIRS=perl INSTALLMAN1DIR=none
> INSTALLMAN3DIR=none PERL_CORE=1 LIBPERL_A=libperl.so
>> -1 from cpan/Archive-Extract's Makefile.PL at make_ext.pl line 409.
>> Warning: No Makefile!
>> /home/bernd/.fbr/build/output/host/usr/bin/make config PERL_CORE=1
> LIBPERL_A=libperl.so failed, continuing anyway...
>> Making all in cpan/Archive-Extract
>> /home/bernd/.fbr/build/output/build/perl-5.16.1/Cross/run-qemu-i386
> /home/bernd/.fbr/build/output/host/usr/bin/make all PERL_CORE=1
> LIBPERL_A=libperl.so
>> Unsuccessful make(cpan/Archive-Extract): code=-1 at make_ext.pl line 468.
>> make[1]: *** [cpan/Archive-Extract/pm_to_blib] Fehler 22
>> make[1]: Leaving directory `/home/bernd/.fbr/build/output/build/perl-
> 5.16.1'
>> make: *** [/home/bernd/.fbr/build/output/build/perl-5.16.1/.stamp_built]
> Fehler 2
>
> Executing the last command alone provides this error hinting at a problem
> with host-qemu, which I was able to solve yet.
>
> $ /home/bernd/.fbr/build/output/build/perl-5.16.1/Cross/run-qemu-i386
> /home/bernd/.fbr/build/output/host/usr/bin/make all PERL_CORE=1
> LIBPERL_A=libperl.so
> qemu: Unsupported syscall: 240
> qemu: Unsupported syscall: 240
>
> First I got this error message with Debian Squeeze i386 (virtualbox guest,
> Win XP host), but also on Debian wheezy amd64 running non-virtualized.
>
> My .config can be found here: http://pastebin.com/yz1SzeB2
> I am using buildroot as part of the FLI4L source package[1].
>
> Kind regards, Bernd
>
I could reproduce the lastest problem on the HEAD of Buildroot with
qemu_x86_defconfig (which is a smaller config than your FLI4L config).
Fran?ois
> [1] http://www.fli4l.de/download/tarball-version/aktuell.html
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply
* [Buildroot] BR2_PREFER_STATIC_LIB and LDFLAGS+= -static
From: ANDY KENNEDY @ 2012-11-05 16:24 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50944786.4040407@mind.be>
> On 11/02/12 18:06, ANDY KENNEDY wrote:
> > All,
> >
> > Near line 302 in package/Makefile.in was added TARGET_LDFLAGS += -static
> > to satisfy a request I made a while back. This really needs to be
> > --static so that it filters down through autoconf the correct way. If
> > -static is passed in LDFLAGS, autoconf regularly mishandles this by
> > setting a variable then never reconfiguring the package's make system
> > to build static. However, the --static to ld is the same as -static,
> > but autoconf does not compare for --static, thus, packages get built as
> > desired.
>
> I don't really understand how it can go wrong... Can you give an example
> of a package with a configure script that handles it the wrong way?
kexec, htop, proftpd, dropbear, etc.
kexec is special in that it also has kdump which I never figured out how
to get that make system to build it static (I drop it off, however, as I
don't need it).
>
> >
> > Can someone change this in package/Makefile.in or should I submit a
> > dinky patch for this?
>
> Yes, please submit a patch.
>
> 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] new perl build issue
From: François Perrad @ 2012-11-05 14:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CABtOAfy84BF1p_KZ2m3sqr-o72xuj_TL1eZfQj-BsH5Z+kmnWA@mail.gmail.com>
2012/11/5 Alexander Khryukin <alexander@mezon.ru>:
>
>
> 2012/11/5 Alexander Khryukin <alexander@mezon.ru>
>>
>>
>>
>> 2012/11/5 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>>
>>>
>>> On Sun, 4 Nov 2012 20:41:45 +0100, Fran?ois Perrad wrote:
>>>
>>> > this afternoon, Thomas has posted 3 patches for qemu (see
>>> > http://patchwork.ozlabs.org/patch/197055/).
>>> > Alexander, try to rebuild host-qemu with them.
>>>
>>> Unfortunately, none of those patches have a chance to fix Alexander's
>>> problem. My patches only fix missing dependencies.
>>>
>>> Also, could you have a look at http://autobuild.buildroot.org/ for perl
>>> build failures? It seems like Qemu doesn't start properly on some
>>> platforms, for some reason.
>>>
>>> Thomas
>>> --
>>> Thomas Petazzoni, Free Electrons
>>> Kernel, drivers, real-time and embedded Linux
>>> development, consulting, training and support.
>>> http://free-electrons.com
>>
>>
>>
>> I applied your patch but looks it not helps me.
>>
>> http://pastie.org/5188031
>
>
>
> Also if i compile it by my default system gcc it's ok
>
>
> [fdkit at kvm-host UU]$ gcc try.c
> [fdkit at kvm-host UU]$ ls ./a.out
> ./a.out*
> [fdkit at kvm-host UU]$ ./a.out
> Ok
>
Alexander,
the 'qemu-arm' built by Buildroot doesn't work properly.
could you try this workaround ?
1) install a 'qemu-arm' with your distro package manager,
$ apt-get install qemu-kvm-extras # or equivalent
2) apply this patch :
--- a/package/perl/perl.mk
+++ b/package/perl/perl.mk
@@ -22,7 +22,7 @@ endif
PERL_CONF_OPT = -des \
-Dusecrosscompile \
- -Dtargetrun=$(QEMU_USER) \
+ -Dtargetrun=qemu-arm \
-Dqemulib=$(STAGING_DIR) \
-Dar="$(TARGET_AR)" \
-Dcc="$(TARGET_CC)" \
Fran?ois
^ permalink raw reply
* [Buildroot] new perl build issue
From: François Perrad @ 2012-11-05 14:24 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121105075317.75f9f85c@skate>
2012/11/5 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
>
> On Sun, 4 Nov 2012 20:41:45 +0100, Fran?ois Perrad wrote:
>
>> this afternoon, Thomas has posted 3 patches for qemu (see
>> http://patchwork.ozlabs.org/patch/197055/).
>> Alexander, try to rebuild host-qemu with them.
>
> Unfortunately, none of those patches have a chance to fix Alexander's
> problem. My patches only fix missing dependencies.
>
> Also, could you have a look at http://autobuild.buildroot.org/ for perl
> build failures? It seems like Qemu doesn't start properly on some
> platforms, for some reason.
on autobuilder, at the first time to run Qemu, there is the same error :
> I've tried to compile and run the following simple program:
>
> #include <stdio.h>
> int main() { printf("Ok\n"); return(0); }
>
> I used the command:
>
> /home/peko/scratch/host/usr/bin/powerpc-linux-gcc -o try ... try.c ... -lc
> /home/peko/scratch/build/perl-5.16.1/Cross/run-qemu-ppc ./try
>
> and I got the following output:
>
> Unable to reserve 0xf7000000 bytes of virtual address space for use
> as guest address space (check your virtual memory ulimit setting
> or reserve less using -R option)
> The program compiled OK, but exited with status 1.
> You have a problem. Shall I abort Configure [y]
Qemu wants ~4GB of RAM for starting, it is really huge.
Fran?ois
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 2/2] linux: bump 3.6.x stable version
From: Gustavo Zacarias @ 2012-11-05 13:53 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352123620-16466-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
linux/Config.in | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/linux/Config.in b/linux/Config.in
index 60d7794..277ef0e 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -21,7 +21,7 @@ choice
prompt "Kernel version"
config BR2_LINUX_KERNEL_3_6
- bool "3.6.5"
+ bool "3.6.6"
config BR2_LINUX_KERNEL_SAME_AS_HEADERS
bool "Same as toolchain kernel headers"
@@ -76,7 +76,7 @@ config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION
config BR2_LINUX_KERNEL_VERSION
string
- default "3.6.5" if BR2_LINUX_KERNEL_3_6
+ default "3.6.6" if BR2_LINUX_KERNEL_3_6
default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS
default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION
default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] kernel-headers: bump 3.{0, 4, 6}.x stable versions
From: Gustavo Zacarias @ 2012-11-05 13:53 UTC (permalink / raw)
To: buildroot
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
| 6 +++---
...all-fix-__packed-in-exported-kernel-head.patch} | 0
2 files changed, 3 insertions(+), 3 deletions(-)
rename toolchain/kernel-headers/{linux-3.0.50-headers_install-fix-__packed-in-exported-kernel-head.patch => linux-3.0.51-headers_install-fix-__packed-in-exported-kernel-head.patch} (100%)
--git a/toolchain/kernel-headers/Config.in b/toolchain/kernel-headers/Config.in
index d596870..e195def 100644
--- a/toolchain/kernel-headers/Config.in
+++ b/toolchain/kernel-headers/Config.in
@@ -67,12 +67,12 @@ config BR2_DEFAULT_KERNEL_HEADERS
default "2.6.37.6" if BR2_KERNEL_HEADERS_2_6_37
default "2.6.38.8" if BR2_KERNEL_HEADERS_2_6_38
default "2.6.39.4" if BR2_KERNEL_HEADERS_2_6_39
- default "3.0.50" if BR2_KERNEL_HEADERS_3_0
+ default "3.0.51" if BR2_KERNEL_HEADERS_3_0
default "3.1.10" if BR2_KERNEL_HEADERS_3_1
default "3.2.33" if BR2_KERNEL_HEADERS_3_2
default "3.3.8" if BR2_KERNEL_HEADERS_3_3
- default "3.4.17" if BR2_KERNEL_HEADERS_3_4
+ default "3.4.18" if BR2_KERNEL_HEADERS_3_4
default "3.5.7" if BR2_KERNEL_HEADERS_3_5
- default "3.6.5" if BR2_KERNEL_HEADERS_3_6
+ default "3.6.6" if BR2_KERNEL_HEADERS_3_6
default "2.6" if BR2_KERNEL_HEADERS_SNAP
default $BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION
diff --git a/toolchain/kernel-headers/linux-3.0.50-headers_install-fix-__packed-in-exported-kernel-head.patch b/toolchain/kernel-headers/linux-3.0.51-headers_install-fix-__packed-in-exported-kernel-head.patch
similarity index 100%
rename from toolchain/kernel-headers/linux-3.0.50-headers_install-fix-__packed-in-exported-kernel-head.patch
rename to toolchain/kernel-headers/linux-3.0.51-headers_install-fix-__packed-in-exported-kernel-head.patch
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCHv3] QtSerialPort: new package
From: Thiago A. Corrêa @ 2012-11-05 13:37 UTC (permalink / raw)
To: buildroot
In-Reply-To: <87y5iiy6pw.fsf@dell.be.48ers.dk>
Hi Peter,
On Sat, Nov 3, 2012 at 2:46 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>
> Thomas a while ago posted patches for qtextserialport:
>
> http://patchwork.ozlabs.org/patch/162431/
>
> What is the relation between qtserialport and qtextserialport? Do we
> need both?
I'm not sure if there is a relation between the two, but qtserialport
(this package) is under the Qt Project umbrella (Repository, Gerrit
code review, CI Servers/Tests). Currently it's under the playground
repository but it has already been voted for graduation from
playground on the development mailing list. Should be an "official"
addon soon.
> Thiago> +define QTSERIALPORT_INSTALL_STAGING_CMDS
> Thiago> + $(MAKE) -C $(@D)/src install
> Thiago> + mv $(HOST_DIR)/usr/include/QtAddOnSerialPort $(STAGING_DIR)/usr/include/
>
> That seems funky. Why is it installing under HOST_DIR in the first
> place?
Beats me :(
The makefile generated by qmake is installing them there. Haven't
found a better way to fix that so far.
> Thiago> +endef
> Thiago> +
> Thiago> +define QTSERIALPORT_INSTALL_TARGET_CMDS
> Thiago> + cp -dpfr $(STAGING_DIR)/usr/lib/libSerialPort.so.* \
> Thiago> + $(TARGET_DIR)/usr/lib
>
> Normally we install headers to target as well. Does the makefile install
> target not support DESTDIR?
>
Unfortunally, no.
Shouldn't the headers be installed to target only if the target has a
compiler? Or should I copy there unconditionally?
Kind Regards,
Thiago A. Correa
^ permalink raw reply
* [Buildroot] Build root local site method
From: Vasanth Ragavendran @ 2012-11-05 12:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CADfuMF4YnAPm_m6YbjO0oCYPJKxqgGwX9amz7SOXhRB3x3mewg@mail.gmail.com>
And forgot to mention I'm using the latest buildroot version 2012.08. So it
should work but I'm not sure if I'm missing something. Plz help.
On Mon, Nov 5, 2012 at 8:41 PM, Vasanth Ragavendran <
ragavendra.2007@gmail.com> wrote:
> Hi
>
> This is with reference to the download method which is specified while
> compiling a new package. I'm writing certain programs which needs to be
> cross compiled and run in my embedded board. In my <pkg>.mk file I'm
> specifying the 'site' to the directory containing my source code and the
> 'site_method' to "local". I've made necessary changes to the Config.in
> files in all locations. I am able to select this package of mine from the
> menuconfig, however the package refuses to build for some unknown reason
> neither does the build print any errors. It just quietly skips compiling
> this package and finishes generating the file system. And the location
> which I'm pointing to in the mk file contains the necessary source code.
> I'm wondering what step I've skipped. Attaching the Config.in and <pkg>.mk
> file which I've created for my package. Kindly help as I'm struck in this
> and unable to proceed. I've referred to the manual but unable to solve this
> issue.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121105/03879e3f/attachment.html>
^ permalink raw reply
* [Buildroot] Build root local site method
From: Vasanth Ragavendran @ 2012-11-05 12:41 UTC (permalink / raw)
To: buildroot
Hi
This is with reference to the download method which is specified while
compiling a new package. I'm writing certain programs which needs to be
cross compiled and run in my embedded board. In my <pkg>.mk file I'm
specifying the 'site' to the directory containing my source code and the
'site_method' to "local". I've made necessary changes to the Config.in
files in all locations. I am able to select this package of mine from the
menuconfig, however the package refuses to build for some unknown reason
neither does the build print any errors. It just quietly skips compiling
this package and finishes generating the file system. And the location
which I'm pointing to in the mk file contains the necessary source code.
I'm wondering what step I've skipped. Attaching the Config.in and <pkg>.mk
file which I've created for my package. Kindly help as I'm struck in this
and unable to proceed. I've referred to the manual but unable to solve this
issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121105/bd1e2407/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Config.in
Type: application/octet-stream
Size: 235 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121105/bd1e2407/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ftpclient.mk
Type: application/octet-stream
Size: 625 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121105/bd1e2407/attachment-0001.obj>
^ permalink raw reply
* [Buildroot] Fwd: Re: mesa3d: "ImportError: No module named
From: Maxime Ripard @ 2012-11-05 12:38 UTC (permalink / raw)
To: buildroot
In-Reply-To: <5097B350.8020701@free-electrons.com>
-------- Message original --------
Sujet: Re: [Buildroot] mesa3d: "ImportError: No module named
Date : Mon, 05 Nov 2012 13:38:40 +0100
De : Maxime Ripard <maxime.ripard@free-electrons.com>
Pour : Vellemans, Noel <Noel.Vellemans@visionBMS.com>
Hi,
(Please keep the mailing list in CC)
Le 05/11/2012 11:20, Vellemans, Noel a ?crit :
> Hi Maxime,
>
>
> I'm still trying to dig a little deeper into the problem.
>
> Is this reproducible?
> Yes, if you delete de mesa3d output directory completely you also run
> into the same problem (so there is no need to have a CLEAN output
> directory)
>
>
> Some info:
> TARGET : ARM - imx537
>
> HOST: Ubuntu 64 bit
> HOST-Python: 2.6.6 (see HOST-python_version.txt)
>
>>> Also, do you know what python interpreter it is actually using?
>>> The one found in your distribution or host-python built by Buildroot?
>
> At this time (as test) I did rename the host-python [ sudo mv
> /usr/bin/python /usr/bin/_python ]
> and buildroot bails out with you must install python on your
> build-machine.
> So I "guess" (which is not my best) buildroot is using the host-python
> (2.6.6).
Ok, so basically, you will probably need to do a few things here to get
that fixed I guess:
- In libxml2, remove the --without-python option if python emulator is
selected
- Make the mesa3d package depends on host-python and host-libxml2 (I
guess?) (basically, just add these two packages to MESA3D_DEPENDENCIES)
- Make mesa3d use the host-python package we just built instead of the
one found on our distribution
I guess something like that would work. But what are the others think on
making mesa depends on host-python? It looks a bit oe-ish, but I don't
quite see a better way.
Maxime
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [git commit] package: drop games/ subdir
From: Stefan Fröberg @ 2012-11-05 12:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <5097AE66.1080607@mind.be>
5.11.2012 14:17, Arnout Vandecappelle kirjoitti:
> On 11/05/12 12:23, Stefan Fr?berg wrote:
>> 5.11.2012 9:23, Peter Korsgaard kirjoitti:
>>> commit:
>>> http://git.buildroot.net/buildroot/commit/?id=9b809e1a6ad2a82bfe0d2383f69f45ae8c6283bb
>>> branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
>>>
>>> As discussed during the dev day.
>
> Looks like I was distracted when it was discussed, because I didn't
> write it in the
> report. But that's probably not really needed anymore...
>
> [snip]
>> Aww...
>>
>> And I had just finished porting dosbox, DOS emulator that can run old
>> classic DOS games
>> and programs, to buildroot.
>>
>> No games for buildroot developers/users then ?
>
> It just moved out of the games/ subdirectory, e.g. package/doomwad
> instead of
> package/games/doomwad.
>
> The general idea is that the subdirectories are confusing and we want
> to get
> rid of them.
>
Ah, I see.
Well, you are right.
They can be a little confusing.
For example, when I start porting some fresh stuff to buildroot the
first thing I usually do is just throw them under the dir named "hacking"
:D
And only afterwards I start wondering what belongs to what subdir.
Best regards
Stefan
> Regards,
> Arnout
>
^ permalink raw reply
* [Buildroot] [git commit] package: drop games/ subdir
From: Arnout Vandecappelle @ 2012-11-05 12:17 UTC (permalink / raw)
To: buildroot
In-Reply-To: <5097A1CD.30009@petroprogram.com>
On 11/05/12 12:23, Stefan Fr?berg wrote:
> 5.11.2012 9:23, Peter Korsgaard kirjoitti:
>> commit: http://git.buildroot.net/buildroot/commit/?id=9b809e1a6ad2a82bfe0d2383f69f45ae8c6283bb
>> branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
>>
>> As discussed during the dev day.
Looks like I was distracted when it was discussed, because I didn't write it in the
report. But that's probably not really needed anymore...
[snip]
> Aww...
>
> And I had just finished porting dosbox, DOS emulator that can run old
> classic DOS games
> and programs, to buildroot.
>
> No games for buildroot developers/users then ?
It just moved out of the games/ subdirectory, e.g. package/doomwad instead of
package/games/doomwad.
The general idea is that the subdirectories are confusing and we want to get
rid of them.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [git commit] package: drop games/ subdir
From: Stefan Fröberg @ 2012-11-05 11:23 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121105081344.74B5F99BE5@busybox.osuosl.org>
5.11.2012 9:23, Peter Korsgaard kirjoitti:
> commit: http://git.buildroot.net/buildroot/commit/?id=9b809e1a6ad2a82bfe0d2383f69f45ae8c6283bb
> branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
>
> As discussed during the dev day.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> ---
> package/Config.in | 8 ++++----
> package/{games => }/doom-wad/Config.in | 0
> package/{games => }/doom-wad/doom-wad.mk | 0
> package/games/games.mk | 1 -
> package/{games => }/gnuchess/Config.in | 0
> .../gnuchess/gnuchess-5.07-getline-conflicts.patch | 0
> package/{games => }/gnuchess/gnuchess-5.07.patch | 0
> package/{games => }/gnuchess/gnuchess.mk | 0
> package/{games => }/prboom/Config.in | 0
> .../prboom/prboom-2.5.0-libpng-1.4.patch | 0
> package/{games => }/prboom/prboom.mk | 0
> package/{games => }/rubix/Config.in | 0
> .../rubix-1.0.5-dont-use-legacy-functions.patch | 0
> package/{games => }/rubix/rubix-1.0.5.patch | 0
> package/{games => }/rubix/rubix.mk | 0
> 15 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/package/Config.in b/package/Config.in
> index 6125abc..1df099b 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -97,10 +97,10 @@ source "package/yasm/Config.in"
> endmenu
>
> menu "Games"
> -source "package/games/gnuchess/Config.in"
> -source "package/games/prboom/Config.in"
> -source "package/games/doom-wad/Config.in"
> -source "package/games/rubix/Config.in"
> +source "package/gnuchess/Config.in"
> +source "package/prboom/Config.in"
> +source "package/doom-wad/Config.in"
> +source "package/rubix/Config.in"
> endmenu
>
> menu "Graphic libraries and applications (graphic/text)"
> diff --git a/package/games/doom-wad/Config.in b/package/doom-wad/Config.in
> similarity index 100%
> rename from package/games/doom-wad/Config.in
> rename to package/doom-wad/Config.in
> diff --git a/package/games/doom-wad/doom-wad.mk b/package/doom-wad/doom-wad.mk
> similarity index 100%
> rename from package/games/doom-wad/doom-wad.mk
> rename to package/doom-wad/doom-wad.mk
> diff --git a/package/games/games.mk b/package/games/games.mk
> deleted file mode 100644
> index 5813b44..0000000
> --- a/package/games/games.mk
> +++ /dev/null
> @@ -1 +0,0 @@
> -include package/games/*/*.mk
> diff --git a/package/games/gnuchess/Config.in b/package/gnuchess/Config.in
> similarity index 100%
> rename from package/games/gnuchess/Config.in
> rename to package/gnuchess/Config.in
> diff --git a/package/games/gnuchess/gnuchess-5.07-getline-conflicts.patch b/package/gnuchess/gnuchess-5.07-getline-conflicts.patch
> similarity index 100%
> rename from package/games/gnuchess/gnuchess-5.07-getline-conflicts.patch
> rename to package/gnuchess/gnuchess-5.07-getline-conflicts.patch
> diff --git a/package/games/gnuchess/gnuchess-5.07.patch b/package/gnuchess/gnuchess-5.07.patch
> similarity index 100%
> rename from package/games/gnuchess/gnuchess-5.07.patch
> rename to package/gnuchess/gnuchess-5.07.patch
> diff --git a/package/games/gnuchess/gnuchess.mk b/package/gnuchess/gnuchess.mk
> similarity index 100%
> rename from package/games/gnuchess/gnuchess.mk
> rename to package/gnuchess/gnuchess.mk
> diff --git a/package/games/prboom/Config.in b/package/prboom/Config.in
> similarity index 100%
> rename from package/games/prboom/Config.in
> rename to package/prboom/Config.in
> diff --git a/package/games/prboom/prboom-2.5.0-libpng-1.4.patch b/package/prboom/prboom-2.5.0-libpng-1.4.patch
> similarity index 100%
> rename from package/games/prboom/prboom-2.5.0-libpng-1.4.patch
> rename to package/prboom/prboom-2.5.0-libpng-1.4.patch
> diff --git a/package/games/prboom/prboom.mk b/package/prboom/prboom.mk
> similarity index 100%
> rename from package/games/prboom/prboom.mk
> rename to package/prboom/prboom.mk
> diff --git a/package/games/rubix/Config.in b/package/rubix/Config.in
> similarity index 100%
> rename from package/games/rubix/Config.in
> rename to package/rubix/Config.in
> diff --git a/package/games/rubix/rubix-1.0.5-dont-use-legacy-functions.patch b/package/rubix/rubix-1.0.5-dont-use-legacy-functions.patch
> similarity index 100%
> rename from package/games/rubix/rubix-1.0.5-dont-use-legacy-functions.patch
> rename to package/rubix/rubix-1.0.5-dont-use-legacy-functions.patch
> diff --git a/package/games/rubix/rubix-1.0.5.patch b/package/rubix/rubix-1.0.5.patch
> similarity index 100%
> rename from package/games/rubix/rubix-1.0.5.patch
> rename to package/rubix/rubix-1.0.5.patch
> diff --git a/package/games/rubix/rubix.mk b/package/rubix/rubix.mk
> similarity index 100%
> rename from package/games/rubix/rubix.mk
> rename to package/rubix/rubix.mk
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
Aww...
And I had just finished porting dosbox, DOS emulator that can run old
classic DOS games
and programs, to buildroot.
No games for buildroot developers/users then ?
Regards
Stefan
^ permalink raw reply
* [Buildroot] [PATCH v3] fs/common: Create initial console device
From: Markos Chandras @ 2012-11-05 9:44 UTC (permalink / raw)
To: buildroot
From: Markos Chandras <markos.chandras@imgtec.com>
A /dev/console node must be present in rootfs when the Linux kernel
boots otherwise the kernel will print the following warning:
"Warning: unable to open an initial console"
This is because when we use an initramfs the /dev directory is not
populated at this point. This can cause problems when a program
(e.g ldso with early debugging enabled) opens a standard file
descriptor for read/write before these descriptors are actually
created by the init process later on.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
---
fs/cpio/cpio.mk | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/cpio/cpio.mk b/fs/cpio/cpio.mk
index aa20b41..5533322 100644
--- a/fs/cpio/cpio.mk
+++ b/fs/cpio/cpio.mk
@@ -21,6 +21,8 @@ define ROOTFS_CPIO_ADD_INIT
fi
endef
+PACKAGES_PERMISSIONS_TABLE += /dev/console c 622 0 0 5 1 - - -$(sep)
+
endif # BR2_ROOTFS_DEVICE_CREATION_STATIC
ROOTFS_CPIO_PRE_GEN_HOOKS += ROOTFS_CPIO_ADD_INIT
--
1.7.1
^ permalink raw reply related
* [Buildroot] mesa3d: "ImportError: No module named libxml2"
From: Maxime Ripard @ 2012-11-05 9:38 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1531E53627F1F749B4FE809BF2A4EB6703A24FFD@wetmex10>
Hi,
Le 05/11/2012 10:18, Vellemans, Noel a ?crit :
> Hi all,
>
> I've been test running/building a recent buildroot (git-version)..
>
> I do end up with this error while building mesa3d" "ImportError: No
> module named libxml2" (ONLY if I do build into a clean-output
> directory!)
>
> The strange thing is that when building for a second time it all builds
> fine.
>
> Any clue where to look at?
Could you post your configuration file and the complete failing build log?
Also, do you know what python interpreter it is actually using? The one
found in your distribution or host-python built by Buildroot?
Thanks.
Maxime
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] new perl build issue
From: Alexander Khryukin @ 2012-11-05 9:19 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CABtOAfyXrgHyg2ggDJvYXExhU4RMabsOVRXfAkE0p9+bnGVrZg@mail.gmail.com>
2012/11/5 Alexander Khryukin <alexander@mezon.ru>
>
>
> 2012/11/5 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
>>
>> On Sun, 4 Nov 2012 20:41:45 +0100, Fran?ois Perrad wrote:
>>
>> > this afternoon, Thomas has posted 3 patches for qemu (see
>> > http://patchwork.ozlabs.org/patch/197055/).
>> > Alexander, try to rebuild host-qemu with them.
>>
>> Unfortunately, none of those patches have a chance to fix Alexander's
>> problem. My patches only fix missing dependencies.
>>
>> Also, could you have a look at http://autobuild.buildroot.org/ for perl
>> build failures? It seems like Qemu doesn't start properly on some
>> platforms, for some reason.
>>
>> Thomas
>> --
>> Thomas Petazzoni, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com
>>
>
>
> I applied your patch but looks it not helps me.
>
> http://pastie.org/5188031
>
Also if i compile it by my default system gcc it's ok
[fdkit at kvm-host UU]$ gcc try.c
[fdkit at kvm-host UU]$ ls ./a.out
./a.out*
[fdkit at kvm-host UU]$ ./a.out
Ok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121105/6b672048/attachment.html>
^ permalink raw reply
* [Buildroot] mesa3d: "ImportError: No module named libxml2"
From: Vellemans, Noel @ 2012-11-05 9:18 UTC (permalink / raw)
To: buildroot
Hi all,
I've been test running/building a recent buildroot (git-version)..
I do end up with this error while building mesa3d" "ImportError: No
module named libxml2" (ONLY if I do build into a clean-output
directory!)
The strange thing is that when building for a second time it all builds
fine.
Any clue where to look at?
Regards Noel.
LOG:
Traceback (most recent call last):
File "main/es_generator.py", line 26, in <module>
import APIspecutil as apiutil
Traceback (most recent call last):
File "main/es_generator.py", line 26, in <module>
File
"/data1/buildhome/20120420/latest_git/20121015_git/buildroot/imx537/du8p
e/build/mesa3d-7.10.1/src/mesa/main/APIspecutil.py", line 28, in
<module>
import APIspecutil as apiutil
import libxml2
File
"/data1/buildhome/20120420/latest_git/20121015_git/buildroot/imx537/du8p
e/build/mesa3d-7.10.1/src/mesa/main
import libxml2
ImportError: No module named libxml2
make[3]: *** No rule to make target `main/api_exec_es1.c', needed by
`depend'. Stop.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox