[Buildroot] Pull request buildroot.git (vapier branch)

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

The following changes since commit 7e9c3a387820154fd1355f23c2669072c0c3a5f7:

  docs/news.html: add 2010.11 announce link (2010-11-30 19:50:04 +0100)

are available in the git repository at:
  git://sources.blackfin.uclinux.org/git/users/vapier/buildroot.git vapier

Mike Frysinger (28):
      m4: version bump to 1.4.15
      xz: version bump to 5.0.0
      u-boot: version bump to 2010.09
      rsh-redone: new package for rsh/rlogin clients
      whetstone: new benchmark package
      dhrystone: new benchmark package
      lsuio: new UIO helper package
      pax-utils: new package
      busybox: unify duplicated build steps
      busybox: let buildroot handle stripping
      linux: support unpacked source trees
      linux: drop LDFLAGS override
      linux: add shorter shortcuts
      linux: set a few more initramfs opts for newer kernels
      toolchain: add a USE_MMU build option
      portmap: add nommu support
      portmap: respect target CFLAGS
      portmap: fix clean target to actually clean
      irda-utils: new package for IrDA devices
      libpcap: update static handling
      tcpdump: add patch for nommu systems
      debugging: do not require no stripping
      initial support for Blackfin processors
      gdb: add support for Blackfin gdbserver
      toolchain-external: allow vendor-controlled defaults
      add support for common ABI options (for FLAT)
      TARGET_CFLAGS: convert to kbuild-y style
      target-finalize: punt config scripts too

 Config.in                                          |    4 +-
 Makefile                                           |    3 +-
 boot/u-boot/Config.in                              |   10 +-
 boot/u-boot/u-boot.mk                              |    2 +
 docs/README                                        |    2 +-
 docs/buildroot.html                                |    2 +-
 linux/Config.in                                    |   13 +-
 linux/linux.mk                                     |   70 ++++--
 package/Config.in                                  |    6 +
 package/Makefile.in                                |   67 ++----
 .../busybox-1.17.3/busybox-1.17.3-skip_strip.patch |   26 +++
 package/busybox/busybox.mk                         |   21 +--
 package/dhrystone/Config.in                        |    6 +
 package/dhrystone/Makefile                         |   13 +
 package/dhrystone/dhrystone-2-HZ.patch             |   13 +
 package/dhrystone/dhrystone-2-cmdline-nruns.patch  |   51 +++++
 package/dhrystone/dhrystone-2-exit.patch           |   12 +
 package/dhrystone/dhrystone-2-prototypes.patch     |   21 ++
 package/dhrystone/dhrystone.mk                     |   37 +++
 package/irda-utils/Config.in                       |   19 ++
 package/irda-utils/irda-utils-0.9.18-daemon.patch  |   26 +++
 package/irda-utils/irda-utils-0.9.18-nommu.patch   |   14 ++
 package/irda-utils/irda-utils-0.9.18-subdir.patch  |   16 ++
 package/irda-utils/irda-utils.mk                   |   47 ++++
 package/libpcap/libpcap.mk                         |    7 +-
 package/lsuio/Config.in                            |    6 +
 package/lsuio/lsuio.mk                             |   11 +
 package/m4/m4-1.4.15-uclibc-sched_param-def.patch  |   19 ++
 package/m4/m4.mk                                   |    2 +-
 package/pax-utils/Config.in                        |    6 +
 package/pax-utils/pax-utils.mk                     |   42 ++++
 ...0-0001-README-fix-typo-in-tcp-wrapper-doc.patch |   26 +++
 ...0002-NO_PIE-make-PIE-support-controllable.patch |   53 +++++
 ...K-control-usage-of-fork-for-nommu-systems.patch |  110 +++++++++
 ...ERROR-control-overriding-of-perror-symbol.patch |   46 ++++
 package/portmap/portmap.mk                         |   12 +-
 package/rsh-redone/Config.in                       |   31 +++
 package/rsh-redone/rsh-redone.mk                   |   36 +++
 package/tcpdump/tcpdump-4.1.1-vfork.patch          |  128 +++++++++++
 package/whetstone/Config.in                        |    6 +
 package/whetstone/whetstone.mk                     |   37 +++
 package/xz/xz.mk                                   |    2 +-
 target/Config.in.arch                              |   32 +++-
 target/generic/Config.in                           |   19 ++-
 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch     |  238 ++++++++++++++++++++
 toolchain/gdb/Config.in                            |    7 +-
 toolchain/helpers.mk                               |   14 +-
 toolchain/toolchain-common.in                      |    7 +
 toolchain/toolchain-external/Config.in.2           |   11 +
 toolchain/toolchain-external/ext-tool.mk           |    6 +
 50 files changed, 1304 insertions(+), 111 deletions(-)
 create mode 100644 package/busybox/busybox-1.17.3/busybox-1.17.3-skip_strip.patch
 create mode 100644 package/dhrystone/Config.in
 create mode 100644 package/dhrystone/Makefile
 create mode 100644 package/dhrystone/dhrystone-2-HZ.patch
 create mode 100644 package/dhrystone/dhrystone-2-cmdline-nruns.patch
 create mode 100644 package/dhrystone/dhrystone-2-exit.patch
 create mode 100644 package/dhrystone/dhrystone-2-prototypes.patch
 create mode 100644 package/dhrystone/dhrystone.mk
 create mode 100644 package/irda-utils/Config.in
 create mode 100644 package/irda-utils/irda-utils-0.9.18-daemon.patch
 create mode 100644 package/irda-utils/irda-utils-0.9.18-nommu.patch
 create mode 100644 package/irda-utils/irda-utils-0.9.18-subdir.patch
 create mode 100644 package/irda-utils/irda-utils.mk
 create mode 100644 package/lsuio/Config.in
 create mode 100644 package/lsuio/lsuio.mk
 create mode 100644 package/m4/m4-1.4.15-uclibc-sched_param-def.patch
 create mode 100644 package/pax-utils/Config.in
 create mode 100644 package/pax-utils/pax-utils.mk
 create mode 100644 package/portmap/portmap-6.0-0001-README-fix-typo-in-tcp-wrapper-doc.patch
 create mode 100644 package/portmap/portmap-6.0-0002-NO_PIE-make-PIE-support-controllable.patch
 create mode 100644 package/portmap/portmap-6.0-0003-NO_FORK-control-usage-of-fork-for-nommu-systems.patch
 create mode 100644 package/portmap/portmap-6.0-0004-NO_PERROR-control-overriding-of-perror-symbol.patch
 create mode 100644 package/rsh-redone/Config.in
 create mode 100644 package/rsh-redone/rsh-redone.mk
 create mode 100644 package/tcpdump/tcpdump-4.1.1-vfork.patch
 create mode 100644 package/whetstone/Config.in
 create mode 100644 package/whetstone/whetstone.mk
 create mode 100644 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch

[Buildroot] Pull request buildroot.git (vapier branch)

[Thomas Petazzoni]

Hello Mike,

Here is a review of your patches, comments below. Next time, it'd be
great if you could post the patches together with the pull request. I
know you have posted some earlier versions of them in the past, but
it's good to see them with every pull request, IMO, as it makes the
review process easier.

On Sat,  4 Dec 2010 17:52:01 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

>       m4: version bump to 1.4.15

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       xz: version bump to 5.0.0

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       u-boot: version bump to 2010.09

I already carry this change in my for-2011.02/boards-cleanup branch, as
I said previously. I don't care which one gets merged, either you or me
will fix his patch series depending on which one goes in first. Is this
ok for you ?

>       rsh-redone: new package for rsh/rlogin clients

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       whetstone: new benchmark package

I really don't like the override of the .stamp_extracted step, but
since the software packaging is strange and we don't have support for
such packaging in the infrastructure for the moment:

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       dhrystone: new benchmark package

Same thing here for the override of the .stamp_extracted step, but for
the same reason:

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       lsuio: new UIO helper package

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       pax-utils: new package

Here, I'm sorry but I don't like the cleverness of your
_PAX_UTILS_INSTALL_TARGET_CMDS and _PAX_UTILS_UNINSTALL_TARGET_CMDS.
Could you please make this :

+define HOST_PAX_UTILS_INSTALL_CMDS
+       $(MAKE) -C $(@D) install DESTDIR=$(HOST_DIR)
+endef
+define PAX_UTILS_INSTALL_TARGET_CMDS
+       $(MAKE) -C $(@D) install DESTDIR=$(TARGET_DIR)
+endef

And ditto for the uninstall thing ? (The list of files to remove can be
shared using a variable, though).

I know you're going to say that it's more lines, it's stupid and so on,
but I really thing it's more straightforward to read written this way.

Moreover, pax-utils requires LARGEFILE support, so you have to do the
usual stuff in the Config.in file:

diff --git a/package/pax-utils/Config.in b/package/pax-utils/Config.in
index 76eab6f..d676ca7 100644
--- a/package/pax-utils/Config.in
+++ b/package/pax-utils/Config.in
@@ -1,6 +1,10 @@
 config BR2_PACKAGE_PAX_UTILS
        bool "pax-utils"
+       depends on BR2_LARGEFILE
        help
          ELF related utils to make scripting of ELFs easier
 
          http://hardened.gentoo.org/pax-utils.xml
+
+comment "pax-utils requires a toolchain with LARGEFILE support"
+       depends on !BR2_LARGEFILE

>       busybox: unify duplicated build steps

I'd very much prefer something like:

BUSYBOX_MAKE_OPTS =                       \
	CC="$(TARGET_CC)"                 \
	ARCH=$(KERNEL_ARCH)               \
	PREFIX="$(TARGET_DIR)"            \
	EXTRA_LDFLAGS="$(TARGET_LDFLAGS)" \
	CROSS_COMPILE="$(TARGET_CROSS)"   \
	CONFIG_PREFIX="$(TARGET_DIR)"

And then:

define BUSYBOX_BUILD_CMDS
	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPTS) -C $(@D)
endef

define BUSYBOX_INSTALL_BINARY
	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPTS) -C $(@D) install
endef

I know it's a little bit more code, but it's how we do it in other
packages, so I'd prefer to be consistent.

>       busybox: let buildroot handle stripping

I'm obviously ok on the principle, but we'll have to keep updating the
patch directory and patch name everytime we bump busybox (which happens
quite often). Considering the simple change, wouldn't a $(SED) call
directly in busybox.mk be more future-proof ? Or better, get this patch
merged into Busybox. Anyway, this can be decided later, so:

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       linux: support unpacked source trees

This is a useful feature, but we want to introduce it globally for all
packages, not only for the Linux kernel. This needs some thoughts on
what it should look like, how it should be presented to users, how it
should work.

Could you remove this patch from the patch set, but keep the idea
around ?

>       linux: drop LDFLAGS override

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       linux: add shorter shortcuts

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       linux: set a few more initramfs opts for newer kernels

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       toolchain: add a USE_MMU build option

It doesn't work, the uClibc define is __ARCH_USE_MMU__ and not
__UCLIBC_USE_MMU_. This commit will have to be changed when my
toolchain-improvements patch set goes in, but maybe your patch series
will go first (I don't care). Whichever happens, either you or me will
have to fix something :-)

Once the __ARCH_USE_MMU__ thing is fixed, you get my:

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       portmap: add nommu support

Just curious: why was portmap compiled PIE ? Have you pushed the
patches upstream ?

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       portmap: respect target CFLAGS

Why not after $(MAKE), like CC= ?

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       portmap: fix clean target to actually clean

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       irda-utils: new package for IrDA devices

I know Peter wants a short description + author in each patch. Your
patches are fairly obvious, but that's the rule :)

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       libpcap: update static handling

Could you use LIBPCAP_MAKE_OPT instead ?

>       tcpdump: add patch for nommu systems

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       debugging: do not require no stripping

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       initial support for Blackfin processors

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       gdb: add support for Blackfin gdbserver

You already had my Acked-by on that one.

>       toolchain-external: allow vendor-controlled defaults

I think this could be done with the "toolchain profile" mechanism I
proposed in the toolchain-improvements patch set I posted this morning.
Could you remove this patch for this patch series, so that we can
handle this later ? Thanks!

>       add support for common ABI options (for FLAT)

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       TARGET_CFLAGS: convert to kbuild-y style

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       target-finalize: punt config scripts too

No. What if a package really wants to install a binary called
foobar-config that must be kept on the target ? I know it's unlikely,
but I'd prefer not to have this policy at the global level. Just do
what other packages do: add a post install hook that removes the
pcap-config file.

I tested the Blackfin support (well only the build part of it, since I
don't have hardware to test), and I had a few issues with the default
Busybox configuration:

 * shadow password not supported by the C library shipped in the
   Blackfin toolchain. So either shadow password support should be
   disabled in Busybox, or internal Busybox shadow functions should be
   used.

 * ash is selected, but doesn't not work on !MMU. hush should be
   selected instead.

 * swaponoff does not build.

Maybe package/busybox/busybox.mk should tune the busybox config file to
adjust these options, so that the default Busybox build works for the
user ? Or should we ship a completely different busybox configuration
file for !MMU systems ?

Another (unrelated) question: when using the Blackfin toolchains, I
found out that the linker needs zlib installed on the host, but it
isn't the case with the other toolchains I have. What feature of ld
requires zlib ?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Pull request buildroot.git (vapier branch)

[Thomas Petazzoni]

Mike,

On Sun, 5 Dec 2010 11:57:45 +0100
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Another (unrelated) question: when using the Blackfin toolchains, I
> found out that the linker needs zlib installed on the host, but it
> isn't the case with the other toolchains I have. What feature of ld
> requires zlib ?

Yet another question regarding non-MMU support and support for static
builds in Buildroot. Obviously, not all packages support non-MMU
architectures and/or static build, so it'd be good to not allow the
users to select those packages. So the packages known to work for
non-MMU and/or static build should be clearly identified.

So, what about adding:

	depends on BR2_USE_MMU
	depends on !BR2_PREFER_STATIC_LIB

on all packages, except those that have been validated to work in those
two conditions ?

Of course, it means adding those two depends on lines to a lot of
packages, but I don't see a way of doing the opposite with the kconfig
language.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Sunday, December 05, 2010 07:19:52 Thomas Petazzoni wrote:
> Yet another question regarding non-MMU support and support for static
> builds in Buildroot. Obviously, not all packages support non-MMU
> architectures and/or static build, so it'd be good to not allow the
> users to select those packages. So the packages known to work for
> non-MMU and/or static build should be clearly identified.

you can do shared libs under nommu systems.  binding the two makes no sense.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/11eb6c56/attachment-0001.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Thomas Petazzoni]

On Mon, 6 Dec 2010 01:56:52 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> On Sunday, December 05, 2010 07:19:52 Thomas Petazzoni wrote:
> > Yet another question regarding non-MMU support and support for
> > static builds in Buildroot. Obviously, not all packages support
> > non-MMU architectures and/or static build, so it'd be good to not
> > allow the users to select those packages. So the packages known to
> > work for non-MMU and/or static build should be clearly identified.
> 
> you can do shared libs under nommu systems.  binding the two makes no
> sense.

I know you can do shared libs with no-MMU systems, I've already used
FDPIC on Blackfin, thanks.

I didn't mean those two things to be bound together. But it's well
known that :

 * Some packages do not support static build

 * Some packages do not support no-MMU

Those two sets of packages are not identical, that's why I proposed two
different options. A package that doesn't support static build should
do:

	depends on !BR2_PREFER_STATIC_LIB

and all packages that do not work on !MMU should do

	depends on BR2_USE_MMU

My intention is that users can't mistakenly select packages that do not
build statically and/or do not work on !MMU systems.

Is this more clear ?

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/fd256e41/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Monday, December 06, 2010 14:27:54 Thomas Petazzoni wrote:
> I didn't mean those two things to be bound together. But it's well
> known that :
> 
>  * Some packages do not support static build
> 
>  * Some packages do not support no-MMU
> 
> Those two sets of packages are not identical, that's why I proposed two
> different options. A package that doesn't support static build should
> do:
> 
> 	depends on !BR2_PREFER_STATIC_LIB
> 
> and all packages that do not work on !MMU should do
> 
> 	depends on BR2_USE_MMU
> 
> My intention is that users can't mistakenly select packages that do not
> build statically and/or do not work on !MMU systems.

i follow now.  this makes sense to me.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/d379ac60/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> Those two sets of packages are not identical, that's why I
 Thomas> proposed two different options. A package that doesn't support
 Thomas> static build should do:

 Thomas> 	depends on !BR2_PREFER_STATIC_LIB

 Thomas> and all packages that do not work on !MMU should do

 Thomas> 	depends on BR2_USE_MMU

And as this will be most packages, we should probably do something like
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS - E.G. add this dependency in
package/Config.in instead of moving it down to each individual package.

-- 
Bye, Peter Korsgaard

[Buildroot] Pull request buildroot.git (vapier branch)

[Thomas Petazzoni]

On Tue, 07 Dec 2010 13:28:14 +0100
Peter Korsgaard <jacmet@uclibc.org> wrote:

> And as this will be most packages, we should probably do something
> like BR2_PACKAGE_BUSYBOX_SHOW_OTHERS - E.G. add this dependency in
> package/Config.in instead of moving it down to each individual
> package.

I don't think we should do that. With three options to handle
(BUSYBOX_SHOW_OTHERS, USE_MMU and PREFER_STATIC_LIB), the
package/Config.in is going to become a nightmare to read, and the fact
that the current if's in package/Config.in can be common to several
packages will be very reduced because of the three conditions.

On the opposite, I would have suggested to move these to the
per-package Config.in. Yes, it's a bit more code, but it's not a big
deal, and will make it easier to maintain.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Tuesday, December 07, 2010 07:28:14 Peter Korsgaard wrote:
>  Thomas> Those two sets of packages are not identical, that's why I
>  Thomas> proposed two different options. A package that doesn't support
>  Thomas> static build should do:
>  Thomas> 	depends on !BR2_PREFER_STATIC_LIB
>  Thomas> and all packages that do not work on !MMU should do
>  Thomas> 	depends on BR2_USE_MMU
> 
> And as this will be most packages

what are you basing this on ?  this isnt my experience at all.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101207/ec477bb9/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

 >> And as this will be most packages

 Mike> what are you basing this on ?  this isnt my experience at all.

Nothing but gut feeling. I would expect lots of packages use fork() or
similar.

Out of interest, what packages are you using on nommu?

-- 
Bye, Peter Korsgaard

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Tuesday, December 07, 2010 16:48:02 Peter Korsgaard wrote:
> >>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
>  >> And as this will be most packages
> 
>  Mike> what are you basing this on ?  this isnt my experience at all.
> 
> Nothing but gut feeling. I would expect lots of packages use fork() or
> similar.

fork() is common, but the vast majority of the time it's to do an exec which 
makes them trivial to convert to vfork().  realistically, build problems with 
uClibc vs glibc tend to be more common.

> Out of interest, what packages are you using on nommu?

i've played doom on my hardware, made video/voip calls via linphone, browsed 
the web with qt/webkit, and served web pages from sqlite/php (to name a few).  
we treat it as a generic Linux platform like any other arch rather than 
pigeonhole it as a "firewall" or something.  i dont really keep track as it'd 
kind of be like asking what packages have i used on an mmu.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101207/df1edd4b/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Sunday, December 05, 2010 05:57:45 Thomas Petazzoni wrote:
> Here is a review of your patches, comments below. Next time, it'd be
> great if you could post the patches together with the pull request. I
> know you have posted some earlier versions of them in the past, but
> it's good to see them with every pull request, IMO, as it makes the
> review process easier.

i dont know what you mean by "earlier versions".  these all should be the 
exact same version as i already posted in the past.  if people had feedback on 
the patches, i'd of expected them to be given at the time of patch posting.

> >       u-boot: version bump to 2010.09
> 
> I already carry this change in my for-2011.02/boards-cleanup branch, as
> I said previously. I don't care which one gets merged, either you or me
> will fix his patch series depending on which one goes in first. Is this
> ok for you ?

doesnt matter to me

> >       pax-utils: new package
> 
> I know you're going to say that it's more lines, it's stupid and so on,

you're right

> Moreover, pax-utils requires LARGEFILE support, so you have to do the
> usual stuff in the Config.in file:

why do you say this ?

> >       busybox: unify duplicated build steps
> 
> I'd very much prefer something like:
> 
> BUSYBOX_MAKE_OPTS = ...

i'll take a look

> >       busybox: let buildroot handle stripping
> 
> I'm obviously ok on the principle, but we'll have to keep updating the
> patch directory and patch name everytime we bump busybox (which happens
> quite often). Considering the simple change, wouldn't a $(SED) call
> directly in busybox.mk be more future-proof ? Or better, get this patch
> merged into Busybox. Anyway, this can be decided later, so:

it's already been merged upstream

> >       linux: support unpacked source trees
> 
> This is a useful feature, but we want to introduce it globally for all
> packages, not only for the Linux kernel. This needs some thoughts on
> what it should look like, how it should be presented to users, how it
> should work.
> 
> Could you remove this patch from the patch set, but keep the idea
> around ?

maybe i'm pessimistic, but i doubt that general support will be done in a 
reasonable time frame.  thus wouldnt it make sense to merge this and once 
someone does put together common code, switch the Linux one over to it ?

> >       toolchain: add a USE_MMU build option
> 
> It doesn't work, the uClibc define is __ARCH_USE_MMU__ and not
> __UCLIBC_USE_MMU_. This commit will have to be changed when my
> toolchain-improvements patch set goes in, but maybe your patch series
> will go first (I don't care). Whichever happens, either you or me will
> have to fix something :-)

copy & paste i guess from the other options

> >       portmap: add nommu support
> 
> Just curious: why was portmap compiled PIE ?

redhat takes the general position that network daemons be compiled as PIEs.  
since the portmap maintainer is a redhat employee, he put it into the portmap 
build system instead of keeping it in the redhat spec.  glibc does the same 
thing.

> Have you pushed the patches upstream ?

of course, but the maintainer hasnt updated things in a while.  probably 
because people are moving to rpcbind.

> >       portmap: respect target CFLAGS
> 
> Why not after $(MAKE), like CC= ?

because it will override settings in the portmap make.  setting vars via the 
env and via the command line do not have the same semantics in make.

> >       irda-utils: new package for IrDA devices
> 
> I know Peter wants a short description + author in each patch. Your
> patches are fairly obvious, but that's the rule :)

i dont know what you mean by author.  git already tracks authorship.

> >       libpcap: update static handling
> 
> Could you use LIBPCAP_MAKE_OPT instead ?

i wasnt aware of that, but i guess it should work

> >       toolchain-external: allow vendor-controlled defaults
> 
> I think this could be done with the "toolchain profile" mechanism I
> proposed in the toolchain-improvements patch set I posted this morning.
> Could you remove this patch for this patch series, so that we can
> handle this later ? Thanks!

i'll take a look

> >       target-finalize: punt config scripts too
> 
> No. What if a package really wants to install a binary called
> foobar-config that must be kept on the target ? I know it's unlikely,
> but I'd prefer not to have this policy at the global level. Just do
> what other packages do: add a post install hook that removes the
> pcap-config file.

can you name a package that does this ?  i havent seen one.

> I tested the Blackfin support (well only the build part of it, since I
> don't have hardware to test), and I had a few issues with the default
> Busybox configuration:

which are all fixed by another patch i have which adds defconfigs for Blackfin 
boards.  fixing the default defconfig makes no sense to me so i'm not going to 
spend time on it.

> Another (unrelated) question: when using the Blackfin toolchains, I
> found out that the linker needs zlib installed on the host, but it
> isn't the case with the other toolchains I have. What feature of ld
> requires zlib ?

it isnt ld, it's elf2flt-ld.  and elf2flt supports compression via the ZFLAT 
format.  although in newer binutils, they have added support for compressed 
debug sections which does require zlib in misc utils such as ld ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/e6b33314/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Thomas Petazzoni]

Hello,

On Mon, 6 Dec 2010 02:50:01 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> i dont know what you mean by "earlier versions".  these all should be
> the exact same version as i already posted in the past.  if people
> had feedback on the patches, i'd of expected them to be given at the
> time of patch posting.

I know those were the same, but it really make things easier if patches
come together with the pull request, to ease the review process, even
if they have been posted previously.

> > >       pax-utils: new package
> > 
> > I know you're going to say that it's more lines, it's stupid and so
> > on,
> 
> you're right

I know :-)

> > Moreover, pax-utils requires LARGEFILE support, so you have to do
> > the usual stuff in the Config.in file:
> 
> why do you say this ?

Because when you build it with a toolchain that doesn't support
LARGEFILE you have undefined references to glob64_t. It can probably be
fixed in pax-utils itself, but when we don't want to fix it, we just
mark the package as depending on LARGEFILE.

> > >       busybox: unify duplicated build steps
> > 
> > I'd very much prefer something like:
> > 
> > BUSYBOX_MAKE_OPTS = ...
> 
> i'll take a look

Thanks!

> > >       busybox: let buildroot handle stripping
> > 
> > I'm obviously ok on the principle, but we'll have to keep updating
> > the patch directory and patch name everytime we bump busybox (which
> > happens quite often). Considering the simple change, wouldn't a
> > $(SED) call directly in busybox.mk be more future-proof ? Or
> > better, get this patch merged into Busybox. Anyway, this can be
> > decided later, so:
> 
> it's already been merged upstream

Great.

> > >       linux: support unpacked source trees
> > 
> > This is a useful feature, but we want to introduce it globally for
> > all packages, not only for the Linux kernel. This needs some
> > thoughts on what it should look like, how it should be presented to
> > users, how it should work.
> > 
> > Could you remove this patch from the patch set, but keep the idea
> > around ?
> 
> maybe i'm pessimistic, but i doubt that general support will be done
> in a reasonable time frame.  thus wouldnt it make sense to merge this
> and once someone does put together common code, switch the Linux one
> over to it ?

You're probably right, it'll take some time for us to do this
generally. My position is that in the past too much specific stuff has
been added in Buildroot, offering sometimes duplicate functionality,
and that we should try to avoid that in the future. I just offered my
position on this, but I'm not the Buildroot maintainer, so Peter's
position might be different.

However, as this is a bit controversial, in order to ease the
integration of your patch set, you may want to remove this patch from
this branch, get all the other patches merged, and then try again with
this particular patch only separatly.

> > >       toolchain: add a USE_MMU build option
> > 
> > It doesn't work, the uClibc define is __ARCH_USE_MMU__ and not
> > __UCLIBC_USE_MMU_. This commit will have to be changed when my
> > toolchain-improvements patch set goes in, but maybe your patch
> > series will go first (I don't care). Whichever happens, either you
> > or me will have to fix something :-)
> 
> copy & paste i guess from the other options

Sure, just minor comment after review/testing.

> > >       portmap: add nommu support
> > 
> > Just curious: why was portmap compiled PIE ?
> 
> redhat takes the general position that network daemons be compiled as
> PIEs. since the portmap maintainer is a redhat employee, he put it
> into the portmap build system instead of keeping it in the redhat
> spec.  glibc does the same thing.

Ok, thanks. Do you what's the reasoning behind compiling all network
daemons as PIE ? Is it because of some address space randomization
feature ?

> > Have you pushed the patches upstream ?
> 
> of course, but the maintainer hasnt updated things in a while.
> probably because people are moving to rpcbind.

Should we as well ?

> > >       portmap: respect target CFLAGS
> > 
> > Why not after $(MAKE), like CC= ?
> 
> because it will override settings in the portmap make.  setting vars
> via the env and via the command line do not have the same semantics
> in make.

Yes, makes sense;

> > >       irda-utils: new package for IrDA devices
> > 
> > I know Peter wants a short description + author in each patch. Your
> > patches are fairly obvious, but that's the rule :)
> 
> i dont know what you mean by author.  git already tracks authorship.

Peter still wants the patch we have in Buildroot to carry a description
and an author. The author of the patch may not be the person who
imported it into Buildroot.

> > >       libpcap: update static handling
> > 
> > Could you use LIBPCAP_MAKE_OPT instead ?
> 
> i wasnt aware of that, but i guess it should work

No problem. This is one of the few things that is actually documented
in the Buildroot documentation :-)

> > >       toolchain-external: allow vendor-controlled defaults
> > 
> > I think this could be done with the "toolchain profile" mechanism I
> > proposed in the toolchain-improvements patch set I posted this
> > morning. Could you remove this patch for this patch series, so that
> > we can handle this later ? Thanks!
> 
> i'll take a look

Great thanks. I think it should work reasonably well with Blackfin
toolchains, adding the optional capability of having Buildroot
download/install the toolchain for the user if (s)he wants to. The only
thing I see problematic is that Blackfin toolchains are typically
shipped in two separate tarballs, so a little bit of hacking in
ext-tool.mk might be needed, but nothing that looks impossible.

> > >       target-finalize: punt config scripts too
> > 
> > No. What if a package really wants to install a binary called
> > foobar-config that must be kept on the target ? I know it's
> > unlikely, but I'd prefer not to have this policy at the global
> > level. Just do what other packages do: add a post install hook that
> > removes the pcap-config file.
> 
> can you name a package that does this ?  i havent seen one.

No, I can't name a package that does this. I'd just prefer to be
cautious.

> > I tested the Blackfin support (well only the build part of it,
> > since I don't have hardware to test), and I had a few issues with
> > the default Busybox configuration:
> 
> which are all fixed by another patch i have which adds defconfigs for
> Blackfin boards.  fixing the default defconfig makes no sense to me
> so i'm not going to spend time on it.

Ok. I think we generally want Buildroot to make a working build when
used out-of-the-box. I.e, without using any defconfig, if the user does
"make menuconfig", selects "blackfin" and then exits, the build should
be working. I think Peter quite likes this rule. But for the blackfin
case, we can probably discuss how to solve this later.

> > Another (unrelated) question: when using the Blackfin toolchains, I
> > found out that the linker needs zlib installed on the host, but it
> > isn't the case with the other toolchains I have. What feature of ld
> > requires zlib ?
> 
> it isnt ld, it's elf2flt-ld.  and elf2flt supports compression via
> the ZFLAT format.  although in newer binutils, they have added
> support for compressed debug sections which does require zlib in misc
> utils such as ld ... -mike

Ah, ok, good to know.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/f3ca4286/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Monday, December 06, 2010 14:39:10 Thomas Petazzoni wrote:
> On Mon, 6 Dec 2010 02:50:01 -0500 Mike Frysinger wrote:
> > > Moreover, pax-utils requires LARGEFILE support, so you have to do
> > 
> > > the usual stuff in the Config.in file:
> > why do you say this ?
> 
> Because when you build it with a toolchain that doesn't support
> LARGEFILE you have undefined references to glob64_t. It can probably be
> fixed in pax-utils itself, but when we don't want to fix it, we just
> mark the package as depending on LARGEFILE.

considering i'm one of the authors, i'd rather fix pax-utils upstream.  i see 
no reason for it to be using glob64 code considering we build with _GNU_SOURCE 
which implies LFS which transparently rewrites glob to glob64 with glibc.

> > > >       portmap: add nommu support
> > > 
> > > Just curious: why was portmap compiled PIE ?
> > 
> > redhat takes the general position that network daemons be compiled as
> > PIEs. since the portmap maintainer is a redhat employee, he put it
> > into the portmap build system instead of keeping it in the redhat
> > spec.  glibc does the same thing.
> 
> Ok, thanks. Do you what's the reasoning behind compiling all network
> daemons as PIE ? Is it because of some address space randomization
> feature ?

i'm fairly certain that is why.  if it werent built as a PIE, then using ASLR 
would cause unsharable mappings, and that can quickly suck up resources.

> > > Have you pushed the patches upstream ?
> > 
> > of course, but the maintainer hasnt updated things in a while.
> > probably because people are moving to rpcbind.
> 
> Should we as well ?

the rpcbind stack isnt as friendly (yet) to uClibc.  so it might be an OK 
future plan, but today it wont work out of the box.  and i dont have personal 
interest to get it resolved today.

> > > >       irda-utils: new package for IrDA devices
> > > 
> > > I know Peter wants a short description + author in each patch. Your
> > > patches are fairly obvious, but that's the rule :)
> > 
> > i dont know what you mean by author.  git already tracks authorship.
> 
> Peter still wants the patch we have in Buildroot to carry a description
> and an author. The author of the patch may not be the person who
> imported it into Buildroot.

when using `git am` or `git pull`, it does retain authorship.  i dont see how 
the changeset would make it into the tree unless people were manually doing 
`patch && git commit`.

> > > I tested the Blackfin support (well only the build part of it,
> > > since I don't have hardware to test), and I had a few issues with
> > > the default Busybox configuration:
> > 
> > which are all fixed by another patch i have which adds defconfigs for
> > Blackfin boards.  fixing the default defconfig makes no sense to me
> > so i'm not going to spend time on it.
> 
> Ok. I think we generally want Buildroot to make a working build when
> used out-of-the-box. I.e, without using any defconfig, if the user does
> "make menuconfig", selects "blackfin" and then exits, the build should
> be working. I think Peter quite likes this rule. But for the blackfin
> case, we can probably discuss how to solve this later.

well, it wont be specific to Blackfin, and would probably require digging down 
into mmu/nommu specific options in things like busybox.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/b479194e/attachment-0001.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Thomas Petazzoni]

Hello,

On Mon, 6 Dec 2010 15:20:47 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> considering i'm one of the authors, i'd rather fix pax-utils upstream.  i see 
> no reason for it to be using glob64 code considering we build with _GNU_SOURCE 
> which implies LFS which transparently rewrites glob to glob64 with glibc.

Ok. Here is what I have with my !LARGEFILE toolchain:

/home/test/toolchains/br-arm-basic/usr/bin/arm-linux-gcc --sysroot=/home/test/outputs/pax/staging -Os -mabi=aapcs-linux -msoft-float -D_GNU_SOURCE -o scanelf.o -c scanelf.c
scanelf.c: In function 'load_ld_cache_config':
scanelf.c:1597: error: 'glob64_t' undeclared (first use in this function)
scanelf.c:1597: error: (Each undeclared identifier is reported only once
scanelf.c:1597: error: for each function it appears in.)
scanelf.c:1597: error: expected ';' before 'gl'
scanelf.c:1598: warning: ISO C90 forbids mixed declarations and code
scanelf.c:1608: warning: implicit declaration of function 'glob64'
scanelf.c:1608: warning: nested extern declaration of 'glob64'
scanelf.c:1608: error: 'gl' undeclared (first use in this function)
scanelf.c:1615: warning: implicit declaration of function 'globfree64'
scanelf.c:1615: warning: nested extern declaration of 'globfree64'
make[1]: *** [scanelf.o] Error 1

> > > redhat takes the general position that network daemons be compiled as
> > > PIEs. since the portmap maintainer is a redhat employee, he put it
> > > into the portmap build system instead of keeping it in the redhat
> > > spec.  glibc does the same thing.
> > 
> > Ok, thanks. Do you what's the reasoning behind compiling all network
> > daemons as PIE ? Is it because of some address space randomization
> > feature ?
> 
> i'm fairly certain that is why.  if it werent built as a PIE, then using ASLR 
> would cause unsharable mappings, and that can quickly suck up resources.

Ok, thanks.

> > > > Have you pushed the patches upstream ?
> > > 
> > > of course, but the maintainer hasnt updated things in a while.
> > > probably because people are moving to rpcbind.
> > 
> > Should we as well ?
> 
> the rpcbind stack isnt as friendly (yet) to uClibc.  so it might be an OK 
> future plan, but today it wont work out of the box.  and i dont have personal 
> interest to get it resolved today.

Ok. I am personally not that familiar with portmap/rpcbind.

> > > > >       irda-utils: new package for IrDA devices
> > > > 
> > > > I know Peter wants a short description + author in each patch. Your
> > > > patches are fairly obvious, but that's the rule :)
> > > 
> > > i dont know what you mean by author.  git already tracks authorship.
> > 
> > Peter still wants the patch we have in Buildroot to carry a description
> > and an author. The author of the patch may not be the person who
> > imported it into Buildroot.
> 
> when using `git am` or `git pull`, it does retain authorship.  i dont see how 
> the changeset would make it into the tree unless people were manually doing 
> `patch && git commit`.

I'm not talking about the patches you are sending to Buildroot, but the
patches that are added to packages (i.e patches inside the patches).

For Buildroot patches, obviously Git tracks everything. But not for
the individual package/*/*.patch, which can come from various sources.

> > Ok. I think we generally want Buildroot to make a working build when
> > used out-of-the-box. I.e, without using any defconfig, if the user does
> > "make menuconfig", selects "blackfin" and then exits, the build should
> > be working. I think Peter quite likes this rule. But for the blackfin
> > case, we can probably discuss how to solve this later.
> 
> well, it wont be specific to Blackfin, and would probably require digging down 
> into mmu/nommu specific options in things like busybox.

Yes, it is definitely not Blackfin specific, and is a problem all !MMU
arches would have. But again, we could solve it at a later time, I
don't see that as a problem to get the Blackfin arch support merged.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/24d28f36/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Monday, December 06, 2010 15:44:05 Thomas Petazzoni wrote:
> On Mon, 6 Dec 2010 15:20:47 -0500 Mike Frysinger wrote:
> > > > > >       irda-utils: new package for IrDA devices
> > > > > 
> > > > > I know Peter wants a short description + author in each patch. Your
> > > > > patches are fairly obvious, but that's the rule :)
> > > > 
> > > > i dont know what you mean by author.  git already tracks authorship.
> > > 
> > > Peter still wants the patch we have in Buildroot to carry a description
> > > and an author. The author of the patch may not be the person who
> > > imported it into Buildroot.
> > 
> > when using `git am` or `git pull`, it does retain authorship.  i dont see
> > how the changeset would make it into the tree unless people were
> > manually doing `patch && git commit`.
> 
> I'm not talking about the patches you are sending to Buildroot, but the
> patches that are added to packages (i.e patches inside the patches).

oh, i missed that.  i wrote these patches and sent them upstream.  i'll add 
that metadata.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/0d78bc53/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

The following changes since commit 9f31e2ffa005095206824e08f69da75503e998ab:

  busybox: 1.18.2 fixes for ping, tar and udhcp (2011-02-06 21:48:53 +0100)

are available in the git repository at:
  git://sources.blackfin.uclinux.org/git/users/vapier/buildroot.git vapier

Mike Frysinger (3):
      debugging: do not require no stripping
      initial support for Blackfin processors
      gdb: add support for Blackfin gdbserver

 Config.in                                      |    4 +-
 Makefile                                       |    1 +
 boot/u-boot/Config.in                          |    4 +
 boot/u-boot/u-boot.mk                          |    2 +
 linux/Config.in                                |    2 +-
 linux/linux.mk                                 |    5 +
 target/Config.in.arch                          |   19 ++-
 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch |  238 ++++++++++++++++++++++++
 toolchain/gdb/Config.in                        |    7 +-
 toolchain/toolchain-common.in                  |    2 +-
 10 files changed, 276 insertions(+), 8 deletions(-)
 create mode 100644 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

The following changes since commit c2abc61d028b9e9cc602108ce1ad03942092bed2:

  tcpdump: add patch for nommu systems (2011-01-19 22:52:30 +0100)

are available in the git repository at:
  git://sources.blackfin.uclinux.org/git/users/vapier/buildroot.git vapier

Mike Frysinger (4):
      libpcap: update static handling
      debugging: do not require no stripping
      initial support for Blackfin processors
      gdb: add support for Blackfin gdbserver

 Config.in                                      |    4 +-
 Makefile                                       |    1 +
 boot/u-boot/Config.in                          |    4 +
 boot/u-boot/u-boot.mk                          |    2 +
 linux/Config.in                                |    2 +-
 linux/linux.mk                                 |    5 +
 package/libpcap/libpcap.mk                     |    6 +-
 target/Config.in.arch                          |   19 ++-
 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch |  238 ++++++++++++++++++++++++
 toolchain/gdb/Config.in                        |    7 +-
 toolchain/toolchain-common.in                  |    2 +-
 11 files changed, 277 insertions(+), 13 deletions(-)
 create mode 100644 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

The following changes since commit 54942318f93b12f8166f110905ec7df6e3279a74:

  pciutils: SHARED make opt goes for install too (2011-01-10 14:52:02 +0100)

are available in the git repository at:
  git://sources.blackfin.uclinux.org/git/users/vapier/buildroot.git vapier

Mike Frysinger (7):
      busybox: unify duplicated build steps
      busybox: let buildroot handle stripping
      toolchain: add a USE_MMU build option
      portmap: add nommu support
      portmap: respect target CFLAGS
      portmap: fix clean target to actually clean
      tcpdump: add patch for nommu systems

 package/busybox/busybox.mk                         |   30 ++---
 ...0-0001-README-fix-typo-in-tcp-wrapper-doc.patch |   26 ++++
 ...0002-NO_PIE-make-PIE-support-controllable.patch |   53 ++++++++
 ...K-control-usage-of-fork-for-nommu-systems.patch |  110 +++++++++++++++++
 ...ERROR-control-overriding-of-perror-symbol.patch |   46 +++++++
 package/portmap/portmap.mk                         |   12 ++-
 package/tcpdump/tcpdump-4.1.1-vfork.patch          |  128 ++++++++++++++++++++
 toolchain/helpers.mk                               |    2 +
 toolchain/toolchain-common.in                      |    7 +
 9 files changed, 396 insertions(+), 18 deletions(-)
 create mode 100644 package/portmap/portmap-6.0-0001-README-fix-typo-in-tcp-wrapper-doc.patch
 create mode 100644 package/portmap/portmap-6.0-0002-NO_PIE-make-PIE-support-controllable.patch
 create mode 100644 package/portmap/portmap-6.0-0003-NO_FORK-control-usage-of-fork-for-nommu-systems.patch
 create mode 100644 package/portmap/portmap-6.0-0004-NO_PERROR-control-overriding-of-perror-symbol.patch
 create mode 100644 package/tcpdump/tcpdump-4.1.1-vfork.patch

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

The following changes since commit d8de970bae3744fe830e96a1ae0c4aff6ce47ba1:

  uClibc: sys/ptrace.h fix for 0.9.31 / powerpc so ltrace builds (2010-11-22 10:53:09 +0100)

are available in the git repository at:
  git://sources.blackfin.uclinux.org/git/users/vapier/buildroot.git vapier

Mike Frysinger (5):
      m4: version bump to 1.4.15
      xz: version bump to 5.0.0
      u-boot: version bump to 2010.09
      auto remove empty /usr/share dir
      rsh-redone: new package for rsh/rlogin clients

 Makefile                                          |    1 +
 boot/u-boot/Config.in                             |    6 +++-
 package/Config.in                                 |    1 +
 package/m4/m4-1.4.15-uclibc-sched_param-def.patch |   19 +++++++++++
 package/m4/m4.mk                                  |    2 +-
 package/rsh-redone/Config.in                      |   31 ++++++++++++++++++
 package/rsh-redone/rsh-redone.mk                  |   36 +++++++++++++++++++++
 package/xz/xz.mk                                  |    2 +-
 8 files changed, 95 insertions(+), 3 deletions(-)
 create mode 100644 package/m4/m4-1.4.15-uclibc-sched_param-def.patch
 create mode 100644 package/rsh-redone/Config.in
 create mode 100644 package/rsh-redone/rsh-redone.mk