* [Buildroot] [PATCH v2 3/6] manual: add deprecated-list.txt generation support
From: Samuel Martin @ 2012-11-29 7:47 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354175268-6909-1-git-send-email-s.martin49@gmail.com>
The whole deprecated-list.txt file is generated by the deprecated.py
script by searching for symbols depending on BR2_DEPRECATED in the
Buildroot code base.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
Change since v1:
* rename the script deprecated.py -> gen-deprecated-list.py (to keep consistency)
---
docs/manual/manual.mk | 3 +
support/scripts/gen-deprecated-list.py | 144 +++++++++++++++++++++++++++++++++
2 files changed, 147 insertions(+)
create mode 100755 support/scripts/gen-deprecated-list.py
diff --git a/docs/manual/manual.mk b/docs/manual/manual.mk
index d8437ba..4cd5839 100644
--- a/docs/manual/manual.mk
+++ b/docs/manual/manual.mk
@@ -27,6 +27,9 @@ endef
$(TOPDIR)/docs/manual/package-list.txt:
$(TOPDIR)/support/scripts/gen-manual-pkg-list.sh > $@
+$(TOPDIR)/docs/manual/deprecated-list.txt:
+ python2 $(TOPDIR)/support/scripts/gen-deprecated-list.py > $@
+
################################################################################
# GENDOC -- generates the make targets needed to build asciidoc documentation.
#
diff --git a/support/scripts/gen-deprecated-list.py b/support/scripts/gen-deprecated-list.py
new file mode 100755
index 0000000..cd8c288
--- /dev/null
+++ b/support/scripts/gen-deprecated-list.py
@@ -0,0 +1,144 @@
+#!/usr/bin/env python
+##
+## deprecated-packages.py
+##
+## Author(s):
+## - Samuel MARTIN <s.martin49@gmail.com>
+##
+## Copyright (C) 2012 Samuel MARTIN
+##
+
+# Python 2.7 script searching for kconfig symbols depending on 'BR2_DEPRECATED'
+# and generating (printing to the standard output) the manual file in asciidoc.
+
+import os
+import re
+import sys
+
+
+ASCIIDOC_HEADER = """\
+//
+// Autogenerated file
+//
+
+[[deprecated]]
+Deprecated list
+---------------
+
+The following stuff are marked as _deprecated_ in Buildroot due to
+their status either too old or unmaintained.
+
+// Please check and sort by grepping the source running:
+//
+// $ git grep -EB4 'depends on BR2_DEPRECATED'
+//
+// and:
+//
+// $ git grep -EB4 'depends on BR2_DEPRECATED' | \\
+// grep -Eo '(:|-).*?(config|comment) BR2_.*'
+"""
+
+NOT_SEARCHED = (".git", "board", "configs", "docs", "output", "support")
+
+# Relative path to category data map
+# key: relative path from buildroot topdir to the search location
+# value: (rank_in_menuconfig, category_name, recursive_search)
+# rank_in_menuconfig is used for ordering the diplaying
+# category_name is used in the diplaying
+# recursive_search when searching for deprecated stuff
+CAT_DIR2DATA = {
+ 'arch' : (0, "target architecture", True),
+ '.' : (1, "build options", False),
+ 'toolchain' : (2, "toolchain", True),
+ 'system' : (3, "system configuration", True),
+ 'package' : (4, "package selection", True),
+ 'fs' : (5, "filesystem images", True),
+ 'boot' : (6, "bootloaders", True),
+ 'linux' : (7, "kernel", True),
+ }
+
+DEPR_SYMBOL = "BR2_DEPRECATED"
+
+_REGEX = r"config BR2_(.*?)\n" + \
+ "((.*?(?!config)(prompt|bool|string|int) \"(.*?)\".*?|[^\n]+)\n)*" + \
+ "(.*?(?!config )" + DEPR_SYMBOL + ".*?)\n" + \
+ "((.*?(?!config)(prompt|bool|string|int) \"(.*?)\".*?|[^\n]+)\n)*"
+
+REGEX = re.compile(_REGEX, flags=re.MULTILINE)
+
+
+def _get_buildroot_topdir():
+ topdir = os.path.join(os.path.dirname(__file__), "..", "..")
+ topdir = os.path.abspath(topdir)
+ return topdir
+
+def get_dir_list():
+ root = _get_buildroot_topdir()
+ dirs = ['.']
+ for dir_ in os.listdir(root):
+ if dir_ in NOT_SEARCHED:
+ continue
+ dir__ = os.path.join(root, dir_)
+ if not os.path.isdir(dir__):
+ continue
+ dirs += [dir_]
+ return dirs
+
+def find_deprecated(root, recursive):
+ deprecated = list()
+ for root_, _, files_ in os.walk(root):
+ if not recursive and root_ != root:
+ break
+ for file_ in files_:
+ if not file_.startswith("Config.in"):
+ continue
+ with open(os.path.join(root_, file_), "r") as f:
+ content = f.read()
+ if not DEPR_SYMBOL in content:
+ continue
+ found = REGEX.findall(content)
+ if found:
+ deprecated += found
+ return deprecated
+
+
+class Category():
+
+ def __init__(self, directory):
+ self.path = os.path.join(_get_buildroot_topdir(), directory)
+ rank, name, rec = CAT_DIR2DATA.get(directory, (99, directory, True))
+ self.name = name
+ self.rank = rank
+ self.depr_items = find_deprecated(self.path, rec)
+
+ def __str__(self):
+ items_ = list()
+ for item in self.depr_items:
+ name_ = item[0].lower().replace("_", " ")
+ name_ = re.sub("^package ", "", name_)
+ vers = re.sub(".*?(version )?([0-9].*)", r'\2', name_)
+ if vers:
+ vers = re.sub(" ", ".", vers)
+ name_ = re.sub("(version )?([0-9].*)", vers, name_)
+ symbol = item[4]
+ if not symbol:
+ symbol = item[9]
+ items_ += ["** %-25s +[%s]+" % (name_, symbol)]
+ items_.sort()
+ output = "\n* %s:\n\n" % self.name.capitalize()
+ output += "\n".join(items_)
+ output += "\n"
+ return output
+
+def main():
+ categories = [Category(directory) for directory in get_dir_list()]
+ categories = [category for category in categories if category.depr_items]
+ categories.sort(cmp=lambda x, y: x.rank - y.rank if x.rank != y.rank \
+ else cmp(x.name, y.name))
+ output = ASCIIDOC_HEADER
+ for category in categories:
+ output += str(category)
+ print output
+
+if __name__ == "__main__":
+ main()
--
1.8.0.1
^ permalink raw reply related
* [Buildroot] [PATCH v2 6/6] manual: add generated *-list.txt
From: Samuel Martin @ 2012-11-29 7:47 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354175268-6909-1-git-send-email-s.martin49@gmail.com>
* update package-list.txt (formerly named pkg-list.txt)
* update deprecated-list.txt
* update appendix.txt (which include these 2 generated files)
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
Change since v1:
* regenerate *-list.txt files
---
docs/manual/appendix.txt | 13 ++---
docs/manual/deprecated-list.txt | 68 ++++++++++++++++----------
docs/manual/{pkg-list.txt => package-list.txt} | 10 ++++
3 files changed, 55 insertions(+), 36 deletions(-)
rename docs/manual/{pkg-list.txt => package-list.txt} (99%)
diff --git a/docs/manual/appendix.txt b/docs/manual/appendix.txt
index 6f1e9f3..4524073 100644
--- a/docs/manual/appendix.txt
+++ b/docs/manual/appendix.txt
@@ -5,15 +5,8 @@ Appendix
include::makedev-syntax.txt[]
-[[package-list]]
-Available packages
-------------------
-// docs/manaual/pkg-list.txt is generated using the following command:
-// $ git grep -E '\((autotools|cmake|generic)-package\)' package/ | \
-// cut -d':' -f1 | grep '\.mk$' | \
-// sed -e 's;.*\?/\(.*\?\).mk;* \1;' | \
-// sort > docs/manual/pkg-list.txt
-
-include::pkg-list.txt[]
+// autogenerated
+include::package-list.txt[]
+// autogenerated
include::deprecated-list.txt[]
diff --git a/docs/manual/deprecated-list.txt b/docs/manual/deprecated-list.txt
index 6dc87a4..1efab7f 100644
--- a/docs/manual/deprecated-list.txt
+++ b/docs/manual/deprecated-list.txt
@@ -1,4 +1,6 @@
-// -*- mode:doc -*- ;
+//
+// Autogenerated file
+//
[[deprecated]]
Deprecated list
@@ -7,40 +9,54 @@ Deprecated list
The following stuff are marked as _deprecated_ in Buildroot due to
their status either too old or unmaintained.
-// list generated using the followings command:
+// Please check and sort by grepping the source running:
+//
// $ git grep -EB4 'depends on BR2_DEPRECATED'
-// and
+//
+// and:
+//
// $ git grep -EB4 'depends on BR2_DEPRECATED' | \
// grep -Eo '(:|-).*?(config|comment) BR2_.*'
-//
-// Need manual checks and sorting.
-* Packages:
+* Build options:
-** +busybox+ 1.18.x
-** +customize+
-** +lzma+
-** +microperl+
-** +netkitbase+
-** +netkittelnet+
-** +pkg-config+
-** +squashfs3+
-** +ttcp+
+** have devfiles +[development files in target filesystem]+
+** have documentation +[documentation on the target]+
* Toolchain:
-** +gdb+ 6.8
-** +gdb+ 7.0.1
-** +gdb+ 7.1
-** +kernel headers+ 2.6.37
-** +kernel headers+ 2.6.38
-** +kernel headers+ 2.6.39
+** gcc target +[gcc]+
+** gdb +[Build gdb debugger for the Target]+
+** gdb 6.8 +[gdb 6.8]+
+** gdb 7.0.1 +[gdb 7.0.1]+
+** gdb 7.1 +[gdb 7.1]+
+** kernel headers 2.6.37 +[Linux 2.6.37.x kernel headers]+
+** kernel headers 2.6.38 +[Linux 2.6.38.x kernel headers]+
+** kernel headers 2.6.39 +[Linux 2.6.39.x kernel headers]+
+
+* Package selection:
+
+** autoconf +[autoconf]+
+** automake +[automake]+
+** binutils 2.20 +[binutils 2.20]+
+** busybox 1.18.x +[BusyBox 1.18.x]+
+** customize +[customize]+
+** libtool +[libtool]+
+** lzma +[lzma]+
+** make +[make]+
+** microperl +[microperl]+
+** netkitbase +[netkitbase]+
+** netkittelnet +[netkittelnet]+
+** pkg config +[pkg-config]+
+** squashfs3 +[squashfs3]+
+** ttcp +[ttcp]+
+
+* Filesystem images:
+
+** target rootfs squashfs3 +[3.x]+
* Bootloaders:
-** +u-boot+ 2011-06
-** +u-boot+ 2011-09
-
-* Output images:
+** target uboot 2011.06 +[2011.06]+
+** target uboot 2011.09 +[2011.09]+
-** squashfs3 image
diff --git a/docs/manual/pkg-list.txt b/docs/manual/package-list.txt
similarity index 99%
rename from docs/manual/pkg-list.txt
rename to docs/manual/package-list.txt
index 5d9b54f..d06316f 100644
--- a/docs/manual/pkg-list.txt
+++ b/docs/manual/package-list.txt
@@ -1,3 +1,12 @@
+
+//
+// Autogenerated file
+//
+
+[[package-list]]
+Available packages
+------------------
+
* acl
* acpid
* alsa-lib
@@ -346,6 +355,7 @@
* luaexpat
* luafilesystem
* luajit
+* lua-msgpack-native
* luasocket
* lvm2
* lzma
--
1.8.0.1
^ permalink raw reply related
* [Buildroot] no /etc/hosts error in building root
From: Thomas Petazzoni @ 2012-11-29 8:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <slrnkbdlmd.33p.narkewoody@zuhnb712.local.com>
Dear Woody Wu,
On Thu, 29 Nov 2012 03:31:16 +0000 (UTC), Woody Wu wrote:
> I just removed the output/target directory and want to root filesystem
> to be rebuilt by running 'make' again. But this time I got an error:
This is not supported. You can't remove output/target and expect
Buildroot to reinstall everything.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] no /etc/hosts error in building root
From: Thomas Petazzoni @ 2012-11-29 8:34 UTC (permalink / raw)
To: buildroot
In-Reply-To: <slrnkbdlmd.33p.narkewoody@zuhnb712.local.com>
Dear Woody Wu,
On Thu, 29 Nov 2012 03:31:16 +0000 (UTC), Woody Wu wrote:
> BTW: If I also want the root iamges under output/images directory to be
> regenerated, is that enough to only remobe the output/target and run
> 'make'? I tried something like 'make root-rebuild' and 'make
> rootfs-rebuild' but they do not work.
Just run "make". The images in output/images/ and re-generated from the
contents of output/target at every make invocation.
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 05/51] package/libiscsi: new package
From: Thomas Petazzoni @ 2012-11-29 8:39 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354146890-27380-6-git-send-email-yann.morin.1998@free.fr>
Dear Yann E. MORIN,
On Thu, 29 Nov 2012 00:54:04 +0100, Yann E. MORIN wrote:
> +LIBISCSI_AUTORECONF = YES
> +# Having a m4/ directory is mandatory for autoreconf to work
> +define LIBISCSI_CREATE_M4_DIR
> + mkdir -p $(@D)/m4
> +endef
> +LIBISCSI_PRE_CONFIGURE_HOOKS += LIBISCSI_CREATE_M4_DIR
I think the reason why AUTORECONF=YES is needed should be mention with
a comment on top of it. You don't have any patch touching
configure.{ac,in} or Makefile.am, so the need for AUTORECONF=YES
doesn't seem very obvious.
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 03/51] package/dtc: add option to install programs
From: Thomas Petazzoni @ 2012-11-29 8:40 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354146890-27380-4-git-send-email-yann.morin.1998@free.fr>
Dear Yann E. MORIN,
On Thu, 29 Nov 2012 00:54:02 +0100, Yann E. MORIN wrote:
> There is some (minor?) issues wrt the licensing terms.
> The libfdt library is dual-licensed GPLv2+/BSD-2c, and the
> executables are licensed GPLv2+.
>
> There is no way in BR to properly convey this information.
> So I decided to add some explanatory comments in the .mk
> file, in retaliation. ;-)
As per the discussion during the Developers Days, there is now a way to
convey this information. From the report:
multiple licenses: we don't want to make things very complex. It
doesn't have to be machine-readable (we don't need to support
machine analysis of the license field), so we don't have to
formally decide how the license text must be written. It does make
sense to have some convention, though. Proposal: "GPLv2+ or BSD-2c
for the library, GPLv2+ for the dtc executable".
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 06/51] package/usbredir: new package
From: Thomas Petazzoni @ 2012-11-29 8:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354146890-27380-7-git-send-email-yann.morin.1998@free.fr>
Dear Yann E. MORIN,
On Thu, 29 Nov 2012 00:54:05 +0100, Yann E. MORIN wrote:
> +comment "usbredir requires libusb"
> + depends on !BR2_PACKAGE_LIBUSB
Hum, why a "depends on" and not a "select", like we normally do for
libraries? libusb is not a "big" thing, so I'd say it should be
automatically selected.
> diff --git a/package/usbredir/usbredir.mk b/package/usbredir/usbredir.mk
> new file mode 100644
> index 0000000..9f6c011
> --- /dev/null
> +++ b/package/usbredir/usbredir.mk
> @@ -0,0 +1,31 @@
> +#############################################################
> +#
> +# usbredir
> +#
> +#############################################################
> +
> +USBREDIR_VERSION = 0.4.3
> +USBREDIR_SOURCE = usbredir-$(USBREDIR_VERSION).tar.bz2
> +USBREDIR_SITE = http://spice-space.org/download/usbredir
> +USBREDIR_LICENSE = LGPLv2.1+
Maybe:
USBREDIR_LICENSE = LGPLv2.1+ (library)
> +USBREDIR_LICENSE_FILES = COPYING.LIB
> +USBREDIR_INSTALL_STAGING = YES
> +USBREDIR_DEPENDENCIES = libusb
> +
> +USBREDIR_DEPENDENCIES += host-pkgconf
> +
> +ifeq ($(BR2_PACKAGE_USBREDIR_SERVER),y)
> +
> +USBREDIR_LICENSE += GPLv2+
USBREDIR_LICENSE += , GPLv2+ (server)
Or something equivalent, as per the conclusion of the Buildroot
Developer Days.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] Buildroot and ClassPath
From: Alain Mouflet @ 2012-11-29 8:50 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129094247.03f7c7d2@skate>
Hello,
I'm trying to add classPath and Jamvm to build root.
I've got the fixjava.patch of D.Smyth then I can compile jamvm but... on
my rootfs, I haven't the /usr/share/classpath/ directory...
What's happens ?
Thank a lot,
Alain
^ permalink raw reply
* [Buildroot] no /etc/hosts error in building root
From: Woody Wu @ 2012-11-29 8:51 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129093344.0d4c46a0@skate>
On 2012-11-29, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>
wrote:
> Dear Woody Wu,
>
> On Thu, 29 Nov 2012 03:31:16 +0000 (UTC), Woody Wu wrote:
>
>> I just removed the output/target directory and want to root filesystem
>> to be rebuilt by running 'make' again. But this time I got an error:
>
> This is not supported. You can't remove output/target and expect
> Buildroot to reinstall everything.
>
> Best regards,
>
> Thomas
Yes, I understood. After did that, I now already get a strange error
in building. Now I had already delete everything from the disck and
trying to rebuild from scratch.
Thanks.
--
woody
I can't go back to yesterday - because I was a different person then.
^ permalink raw reply
* [Buildroot] no /etc/hosts error in building root
From: Woody Wu @ 2012-11-29 8:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129093416.2cf28e51@skate>
On 2012-11-29, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>
wrote:
> Dear Woody Wu,
>
> On Thu, 29 Nov 2012 03:31:16 +0000 (UTC), Woody Wu wrote:
>
>> BTW: If I also want the root iamges under output/images directory to be
>> regenerated, is that enough to only remobe the output/target and run
>> 'make'? I tried something like 'make root-rebuild' and 'make
>> rootfs-rebuild' but they do not work.
>
> Just run "make". The images in output/images/ and re-generated from the
> contents of output/target at every make invocation.
>
> Thomas
This is a good news. Thanks.
--
woody
I can't go back to yesterday - because I was a different person then.
^ permalink raw reply
* [Buildroot] Problem building libglib2
From: Arnout Vandecappelle @ 2012-11-29 9:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201211291121.46456.manningc2@actrix.gen.nz>
On 28/11/12 23:21, Charles Manning wrote:
> On Thursday 29 November 2012 10:59:04 Arnout Vandecappelle wrote:
[snip]
>> Could you (and Alex):
>> - tell us which host environment you have;
>> - re-run the failed build with 'V=1 make libglib2' and
>> post the failed command (should be something starting with:
>> /bin/sh ../../libtool --tag=CC --mode=link ...)
>> - post output/build/libglib2-2.30.3/config.log
>> - post output/build/libglib2-2.30.3/gobject/Makefile
>>
>>
>> I vaguely remember having seen this problem before, but can't remember
>> if and how I solved it :-(
>
> Thanks for the help so far...
>
> I get this problem on my main work PC which is running Ubuntu 10.10 x32. It
> works OK on a machine with Ubuntu 10.04 x64.
So the link command ran by libtool is:
/opt/buildroot/buildroot/output/host/usr/bin/arm-none-linux-gnueabi-gcc -shared -fPIC -DPIC
.libs/libgobject_2_0_la-gatomicarray.o .libs/libgobject_2_0_la-gbinding.o .libs/libgobject_2_0_la-gboxed.o
.libs/libgobject_2_0_la-gclosure.o .libs/libgobject_2_0_la-genums.o .libs/libgobject_2_0_la-gmarshal.o
.libs/libgobject_2_0_la-gobject.o .libs/libgobject_2_0_la-gparam.o .libs/libgobject_2_0_la-gparamspecs.o
.libs/libgobject_2_0_la-gsignal.o .libs/libgobject_2_0_la-gsourceclosure.o .libs/libgobject_2_0_la-gtype.o
.libs/libgobject_2_0_la-gtypemodule.o .libs/libgobject_2_0_la-gtypeplugin.o .libs/libgobject_2_0_la-gvalue.o
.libs/libgobject_2_0_la-gvaluearray.o .libs/libgobject_2_0_la-gvaluetransform.o .libs/libgobject_2_0_la-gvaluetypes.o
-Wl,-rpath -Wl,/opt/buildroot/buildroot/output/build/libglib2-2.30.3/glib/.libs -Wl,-rpath
-Wl,/opt/buildroot/buildroot/output/build/libglib2-2.30.3/gthread/.libs
-L/opt/buildroot/buildroot/output/build/libglib2-2.30.3/glib/.libs ../glib/.libs/libglib-2.0.so ../
gthread/.libs/libgthread-2.0.so -lpthread
/opt/buildroot/buildroot/output/build/libglib2-2.30.3/glib/.libs/libglib-2.0.so -lrt
-L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -lffi -Os -Wl,-Bsymbolic-functions -Wl,-soname
-Wl,libgobject-2.0.so.0 -Wl,-version-script -Wl,.libs/libgobject-2.0.ver -o .libs/libgobject-2.0.so.0.3000.3
(Just to be sure, could you go to the gobject directory and run the
above command to verify that it fails in the same way? And also add the
-v option to it, so we can see how exactly gcc calls ld.)
There are two strange things with this:
1. There is no mention at all of /lib or /usr/lib so why is ld looking
for pthread in those paths?
2. libtool adds -L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib
-- where does that come from?
Maybe there's something fishy in your environment. Can you run
env | grep /lib
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] Buildroot for avr32
From: David Collier @ 2012-11-29 10:20 UTC (permalink / raw)
To: buildroot
Hi - we have a design based on the AVR32.
Historically Atmel provided a "special-buildroot-for-AVR32". Trouble is
their only AVR32 that ran Linux is now end-of-life, and I'm not sure they
have any interest.
The last version of it I can find is based on a buildroot that is 2 years
out of date.
So the question is - should I be able to use "standard buildroot" with an
AVR32 - or was Atmel adding some magic of their own that has not been
back-ported to the main trunk?
TVM
David
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Thomas Petazzoni @ 2012-11-29 10:37 UTC (permalink / raw)
To: buildroot
In-Reply-To: <memo.20121129102031.4232H@postmaster+dexdyne.com.cix.co.uk>
Dear David Collier,
On Thu, 29 Nov 2012 10:20 +0000 (GMT Standard Time), David Collier
wrote:
> Hi - we have a design based on the AVR32.
Aaah great!
> Historically Atmel provided a "special-buildroot-for-AVR32". Trouble is
> their only AVR32 that ran Linux is now end-of-life, and I'm not sure they
> have any interest.
>
> The last version of it I can find is based on a buildroot that is 2 years
> out of date.
>
> So the question is - should I be able to use "standard buildroot" with an
> AVR32 - or was Atmel adding some magic of their own that has not been
> back-ported to the main trunk?
Good to see someone using AVR32. We've been wondering what to do with
our AVR32 support, because not many people have been using it.
Normally, we have a working AVR32 setup, with certainly old versions of
uClibc, binutils and gdb. I was told by AVR32 people that upgrading to
uClibc 0.9.33 should work, but there are a few missing system calls in
the AVR32 upstream kernel. If you are interested, we can look at this
together, as I lack AVR32 hardware to dive into this.
So, I would definitely be interested if you could try out the mainline
Buildroot, and report what the problems are (if any), and we'll see how
to move from here.
Of course, if you are aware of the availability for AVR32 of a more
recent gcc than the 4.2.x we're using and a more recent binutils than
the 2.18 we're using, we're interested as well.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Bjørn Forsman @ 2012-11-29 11:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <memo.20121129102031.4232H@postmaster+dexdyne.com.cix.co.uk>
On 29 November 2012 11:20, David Collier <from_buildroot@dexdyne.com> wrote:
> Hi - we have a design based on the AVR32.
>
> Historically Atmel provided a "special-buildroot-for-AVR32". Trouble is
> their only AVR32 that ran Linux is now end-of-life, and I'm not sure they
> have any interest.
>
> The last version of it I can find is based on a buildroot that is 2 years
> out of date.
>
> So the question is - should I be able to use "standard buildroot" with an
> AVR32 - or was Atmel adding some magic of their own that has not been
> back-ported to the main trunk?
>
I'm not sure what Atmel put in their Buildroot fork, but we've been using
mainline buildroot 2010.08 for one of our AVR32 projects. The only thing
needed to make that version build (I think) is to apply this commit:
http://git.buildroot.net/buildroot/commit/?id=96652637ccfd94442224019c54341bf86094366a
But right now I'm actually in the process of switching that project over to
using an ARM device ;-)
Best regards,
Bj?rn Forsman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121129/d749267f/attachment-0001.html>
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Simon Dawson @ 2012-11-29 11:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129113710.63d5676c@skate>
Hi David, Thomas.
On Thu, 29 Nov 2012 10:20 +0000 (GMT Standard Time), David Collier
> So the question is - should I be able to use "standard buildroot" with an
> AVR32 - or was Atmel adding some magic of their own that has not been
> back-ported to the main trunk?
On 29 November 2012 10:37, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Normally, we have a working AVR32 setup, with certainly old versions of
> uClibc, binutils and gdb. I was told by AVR32 people that upgrading to
> uClibc 0.9.33 should work, but there are a few missing system calls in
> the AVR32 upstream kernel. If you are interested, we can look at this
> together, as I lack AVR32 hardware to dive into this.
I'm using mainline Buildroot for a custom board that is based on the
Atmel NGW100 board, with an ap7000 processor. I haven't had any major
problems; I've had to patch the 3.6.x mainline kernel to get the board
to boot from SD card --- I'm not using any Atmel kernel patches.
I'd be very interested in helping with the migration to uClibc 0.9.33.
Simon.
^ permalink raw reply
* [Buildroot] [PATCH 09/33] linux-fusion: fix build
From: Simon Dawson @ 2012-11-29 12:38 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353543503-8952-10-git-send-email-s.martin49@gmail.com>
On 22 November 2012 00:17, Samuel Martin <s.martin49@gmail.com> wrote:
>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
> .../linux-fusion/linux-fusion-fix-include.patch | 52 ++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
> create mode 100644 package/linux-fusion/linux-fusion-fix-include.patch
>
Acked-by: Simon Dawson <spdawson@gmail.com>
Tested-by: Simon Dawson <spdawson@gmail.com>
(built-test on a minimal arm config)
^ permalink raw reply
* [Buildroot] [PATCH 18/33] linux-fusion: bump to version 8.10.4
From: Simon Dawson @ 2012-11-29 12:38 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353543503-8952-19-git-send-email-s.martin49@gmail.com>
On 22 November 2012 00:18, Samuel Martin <s.martin49@gmail.com> wrote:
> Also fix directfb build avoiding the following error to occur
> (since FCEF_FOLLOW has been added in linux-fusion-8.9.0):
>
> libtool: compile: /opt/br/output/host/usr/bin/ccache /opt/br/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../lib -I../../include -I../../lib -DDATADIR=\"/usr/share/directfb-1.4.17\" -DMODULEDIR=\"/usr/lib/directfb-1.4-6\" -D_REENTRANT -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -ffast-math -pipe -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os -g2 -g3 -fno-inline -Wno-inline -D_GNU_SOURCE -finstrument-functions -std=gnu99 -Werror-implicit-function-declaration -MT call.lo -MD -MP -MF .deps/call.Tpo -c call.c -fPIC -DPIC -o .libs/call.o
> call.c: In function 'fusion_call_execute3':
> call.c:311:66: error 'FCEF_FOLLOW' undeclared (first use in this function)
> call.c:311:66: note: each undeclared identifier is reported only once for each function it appears in
> call.c: In function 'fusion_world_flush_calls':
> call.c:444:54: error 'FCEF_FOLLOW' undeclared (first use in this function)
> make[5]: *** [call.lo] Error 1
> make[5]: Leaving directory `/opt/br/output/build/directfb-1.4.17/lib/fusion'
>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
> package/linux-fusion/linux-fusion.mk | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Simon Dawson <spdawson@gmail.com>
Tested-by: Simon Dawson <spdawson@gmail.com>
(built-test on a minimal arm config)
^ permalink raw reply
* [Buildroot] [PATCH] libroxml: bump version to 2.2.1
From: Arnout Vandecappelle @ 2012-11-29 12:58 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354169996-22703-1-git-send-email-blunderer@blunderer.org>
On 29/11/12 07:19, blunderer at blunderer.org wrote:
> From: Tristan Lelong<tristan.lelong@blunderer.org>
>
> Signed-off-by: Tristan Lelong<tristan.lelong@blunderer.org>
> ---
> package/libroxml/libroxml-2.2.0-werror.patch | 22 ----------------------
> package/libroxml/libroxml-2.2.1-werror.patch | 22 ++++++++++++++++++++++
Please send patches with the -M option to git send-email (or format-patch).
That will detect that this is just a rename.
Please also rename it to libroxml-werror.patch, i.e. removing the version
number. Nowadays, the policy is to make patches without version number,
unless a package supports several versions.
Regards,
Arnout
> package/libroxml/libroxml.mk | 2 +-
> 3 files changed, 23 insertions(+), 23 deletions(-)
> delete mode 100644 package/libroxml/libroxml-2.2.0-werror.patch
> create mode 100644 package/libroxml/libroxml-2.2.1-werror.patch
[snip]
--
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] Buildroot and ClassPath
From: Thomas Petazzoni @ 2012-11-29 13:10 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50B721D7.4050607@univ-rouen.fr>
Dear Alain Mouflet,
First of all, please don't use an existing message of the list when
starting a new thread: you break discussion threads.
On Thu, 29 Nov 2012 09:50:31 +0100, Alain Mouflet wrote:
> I'm trying to add classPath and Jamvm to build root.
> I've got the fixjava.patch of D.Smyth then I can compile jamvm but... on
> my rootfs, I haven't the /usr/share/classpath/ directory...
We used to have packages for jamvm and classpath in Buildroot, but
nobody was maintaining/updating them, so we removed them. You can still
find them in the Git history of the project, though.
Regarding your specific problem, it's impossible to help you: you don't
even give the modifications you've made to Buildroot, nor your
Buildroot configuration. There's no way we can help you if you don't
provide all the details needed for us to reproduce the situation you're
seeing.
See http://www.catb.org/esr/faqs/smart-questions.html#beprecise
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Thiago A. Corrêa @ 2012-11-29 13:53 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHt8ZCN5eB8shsxz+gVz6neYbwVC7kE-O=cT66MCTRQNq6o_qQ@mail.gmail.com>
Hi,
On Thu, Nov 29, 2012 at 9:35 AM, Simon Dawson <spdawson@gmail.com> wrote:
>
> I'm using mainline Buildroot for a custom board that is based on the
> Atmel NGW100 board, with an ap7000 processor. I haven't had any major
> problems; I've had to patch the 3.6.x mainline kernel to get the board
> to boot from SD card --- I'm not using any Atmel kernel patches.
>
Same here. I think our u-boot is from atmel, the rest is mainline,
including buildroot. Haven't tried any new buildroot releases thou. We
have moved to ARM but we still have several AVR32's in the field.
Kind Regards,
Thiago A. Correa
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: David Collier @ 2012-11-29 14:58 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAEYzJUFwwAQnBu3opGyLKkpmc98FJL-rfvndtuPns4rATx8A7w@mail.gmail.com>
In article
<CAEYzJUFwwAQnBu3opGyLKkpmc98FJL-rfvndtuPns4rATx8A7w@mail.gmail.com>,
bjorn.forsman at gmail.com (Bj?rn Forsman) wrote:
> I'm not sure what Atmel put in their Buildroot fork, but we've been
> using
> mainline buildroot 2010.08 for one of our AVR32 projects.
I'm not sure what Atmel put in their Buildroot fork, but we've been using
mainline buildroot 2010.08 for one of our AVR32 projects.
yes indeed. That's what's in their buildroot.
I was provoked into this by the fact that on another board I have openVPN
2.1_rc11 , whereas the one on my AVR32 board is 2.0.9
One insists on a particular line in the config file before running user
scripts, and the other won't tolerate it.
So I was hoping to upgrade to a more recent openVPN - and hoping it would
come in a more recent buildroot.
So one interesting question is - does std buildroot include OpenVPN, and
if so what revision :-)
D
^ permalink raw reply
* [Buildroot] [PATCH 03/51] package/dtc: add option to install programs
From: Arnout Vandecappelle @ 2012-11-29 15:00 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354146890-27380-4-git-send-email-yann.morin.1998@free.fr>
On 29/11/12 00:54, Yann E. MORIN wrote:
> By default, we only install the libfdt library.
>
> As suggested by Arnout, add an option that also
> installs the few dtc programs.
>
> Cc: Arnout Vandecappelle<arnout@mind.be>
> Signed-off-by: "Yann E. MORIN"<yann.morin.1998@free.fr>
[snip]
> +# libfdt_install is our own install rule added by our patch
> +DTC_BUILD_RULE=$(if $(BR2_PACKAGE_DTC_BINARY),,libfdt)
> +DTC_INSTALL_RULE=$(if $(BR2_PACKAGE_DTC_BINARY),install,libfdt_install)
> +
I (and I think Peter as well) prefer the more verbose
ifeq ($(BR2_PACKAGE_DTC_BINARY),y)
DTC_INSTALL_RULE = install
else
DTC_BUILD_RULE = libfdt
DTC_INSTALL_RULE = libfdt_install
endif
I would also call it _TARGET instead of _RULE.
> define DTC_BUILD_CMDS
> $(TARGET_CONFIGURE_OPTS) \
> CFLAGS="$(TARGET_CFLAGS)" \
> - $(MAKE) -C $(@D) PREFIX=/usr libfdt
> + $(MAKE) -C $(@D) PREFIX=/usr $(DTC_BUILD_RULE)
> endef
>
> -# libfdt_install is our own install rule added by our patch
> +# For staging, only the library is needed
> define DTC_INSTALL_STAGING_CMDS
> $(MAKE) -C $(@D) DESTDIR=$(STAGING_DIR) PREFIX=/usr libfdt_install
> endef
>
> define DTC_INSTALL_TARGET_CMDS
> - $(MAKE) -C $(@D) DESTDIR=$(TARGET_DIR) PREFIX=/usr libfdt_install
> + $(MAKE) -C $(@D) DESTDIR=$(TARGET_DIR) PREFIX=/usr $(DTC_INSTALL_RULE)
> endef
I would prefer the same rule for staging and target install:
- it doesn't hurt to have the executable in staging;
- it's easier to read if it's the same;
- when we finally get around to creating $(make-package), the default install
commands will be
$(MAKE) -C $(@D) DESTDIR=... $($(PKG)_INSTALL_TARGET)
(where _INSTALL_TARGET is the same for target and staging and defaults to
'install')
Regards,
Arnout
>
> define DTC_CLEAN_CMDS
--
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] Buildroot for avr32
From: Thomas Petazzoni @ 2012-11-29 15:19 UTC (permalink / raw)
To: buildroot
In-Reply-To: <memo.20121129145816.4232J@postmaster+dexdyne.com.cix.co.uk>
Dear David Collier,
On Thu, 29 Nov 2012 14:58 +0000 (GMT Standard Time), David Collier
> So one interesting question is - does std buildroot include OpenVPN, and
> if so what revision :-)
Sure, we have OpenVPN 2.2.2.
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] Buildroot for avr32
From: Thomas Petazzoni @ 2012-11-29 15:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHt8ZCN5eB8shsxz+gVz6neYbwVC7kE-O=cT66MCTRQNq6o_qQ@mail.gmail.com>
Simon,
On Thu, 29 Nov 2012 11:35:18 +0000, Simon Dawson wrote:
> I'd be very interested in helping with the migration to uClibc 0.9.33.
Do you know what is the status of AVR32 support in upstream gcc,
binutils and gdb?
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] Buildroot for avr32
From: Simon Dawson @ 2012-11-29 16:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129162848.5a761c63@skate>
Hi Thomas,
On 29 Nov 2012 15:29, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:
> Do you know what is the status of AVR32 support in upstream gcc,
> binutils and gdb?
No, I don't. I suspect Atmel have all but stopped attempting to upstream
patches for the architecture, but that is pure conjecture.
Simon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121129/5020c7ae/attachment.html>
^ 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