gmane.comp.embedded.crossdev

[PATCH] [PATCH] only include execinfo.h if crashtracesupport is enabled

Peter Korsgaard — 2012-01-02T13:49:40

On systems without backtrace suport (E.G. uClibc depending on config),
execinfo.h might not be available, breaking the build.

Fix it by only including it if enabled.

Signed-off-by: Peter Korsgaard <jacmet-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org>
---
 src/logging/nm-logging.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/src/logging/nm-logging.c b/src/logging/nm-logging.c
index ca6a709..26c8670 100644
--- a/src/logging/nm-logging.c
+++ b/src/logging/nm-logging.c
< at >< at > -23,7 +23,6 < at >< at >
 
 #include <dlfcn.h>
 #include <syslog.h>
-#include <execinfo.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <unistd.h>

beecrypt: Use AC_COMPILE_IFELSE for ICU check for crosscompilation compat

Peter Korsgaard — 2011-12-14T22:43:29

AC_RUN_IFELSE doesn't work when cross compiling, but we can do the
check in the preprocessor instead and use AC_COMPILE_IFELSE.

Signed-off-by: Peter Korsgaard <jacmet-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org>
---
 configure.ac |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: beecrypt-4.2.1/configure.ac
===================================================================
--- beecrypt-4.2.1.orig/configure.ac
+++ beecrypt-4.2.1/configure.ac
< at >< at > -295,13 +295,13 < at >< at >
 if test "$ac_with_cplusplus" = yes; then
   AC_MSG_CHECKING([for IBM's ICU library version >= 2.8])
   AC_LANG_PUSH(C)
-  AC_RUN_IFELSE([
+  AC_COMPILE_IFELSE([
     AC_LANG_PROGRAM([[#include <unicode/uversion.h>]],[[
       #if U_ICU_VERSION_MAJOR_NUM < 2
-      exit(1);
+      #error too old
       #elif U_ICU_VERSION_MAJOR_NUM == 2
       # if U_ICU_VERSION_MINOR_NUM < 8
-      exit(1);
+      #error too old
       # else
       exit(0);
       # endif

beecrypt: Only compile/link cppglue.cxx if--with-cplusplus is used

Peter Korsgaard — 2011-12-14T22:42:00

Bloats libbeecrypt for no use and breaks build on systems without a C++
compiler.

Signed-off-by: Peter Korsgaard <jacmet-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org>
---
 Makefile.am |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Index: beecrypt-4.2.1/Makefile.am
===================================================================
--- beecrypt-4.2.1.orig/Makefile.am
+++ beecrypt-4.2.1/Makefile.am
< at >< at > -62,7 +62,12 < at >< at >
 
 lib_LTLIBRARIES = libbeecrypt.la
 
-libbeecrypt_la_SOURCES = aes.c base64.c beecrypt.c blockmode.c blockpad.c blowfish.c dhies.c dldp.c dlkp.c dlpk.c dlsvdp-dh.c dsa.c elgamal.c endianness.c entropy.c fips186.c hmac.c hmacmd5.c hmacsha1.c hmacsha224.c hmacsha256.c md4.c md5.c hmacsha384.c hmacsha512.c memchunk.c mp.c mpbarrett.c mpnumber.c mpprime.c mtprng.c pkcs1.c pkcs12.c ripemd128.c ripemd160.c ripemd256.c ripemd320.c rsa.c rsakp.c rsapk.c sha1.c sha224.c sha256.c sha384.c sha512.c sha2k32.c sha2k64.c timestamp.c cppglue.cxx
+libbeecrypt_la_SOURCES = aes.c base64.c beecrypt.c blockmode.c blockpad.c blowfish.c dhies.c dldp.c dlkp.c dlpk.c dlsvdp-dh.c dsa.c elgamal.c endianness.c entropy.c fips186.c hmac.c hmacmd5.c hmacsha1.c hmacsha224.c hmacsha256.c md4.c md5.c hmacsha384.c hmacsha512.c memchunk.c mp.c mpbarrett.c mpnumber.c mpprime.c mtprng.c pkcs1.c pkcs12.c ripemd128.c ripemd160.c ripemd256.c ripemd320.c rsa.c rsakp.c rsapk.c sha1.c sha224.c sha256.c sha384.c sha512.c sha2k32.c sha2k64.c timestamp.c
+
+if WITH_CPLUSPLUS
+libbeecrypt_la_SOURCES += cppglue.cxx
+endif
+
 libbeecrypt_la_DEPENDENCIES = $(BEECRYPT_OBJECTS)
 libbeecrypt_la_LIBADD = blowfishopt.lo mpopt.lo sha1opt.lo $(OPENMP_LIBS)
 libbeecrypt_la_LDFLAGS = -no-undefined -version-info $(LIBBEECRYPT_LT_CURRENT):$(LIBBEECRYPT_LT_REVISION):$(LIBBEECRYPT_LT_AGE)

ppc32 TEXTREL fix for binutils-2.22

Mike Frysinger — 2011-12-03T01:58:46

for anyone who targets powerpc, you'll want to make sure to have this fix from 
upstream when using binutils-2.22
-mike

[RFC/PATCH 0/3 v2] fc-cache --root support

Mike Frysinger — 2011-11-08T05:24:58

The point of these patchsets is to add a --root flag to fc-cache so that
people can build up the font cache in a tree other than /.  This is useful
to people cross-compiling, and for non-root building (chroot won't work).

This ignores the cache file format issue (that's a later patchset).

Mike Frysinger (3):
  FcStrPathPlus: new helper function
  FcStat: export for people to use
  fc-cache: add a --root option

 fc-cache/fc-cache.c     |   59 ++++++++++++++++++++++++++++------------------
 fc-cache/fc-cache.sgml  |   11 ++++++++-
 fontconfig/fontconfig.h |   15 ++++++++++++
 src/fccache.c           |   40 ++++++++++++++++++++++++++++---
 src/fccfg.c             |   59 +++++++++++++++++++++++------------------------
 src/fcdir.c             |   13 ++++++++-
 src/fcfreetype.c        |   10 +++++++-
 src/fcint.h             |    2 +
 src/fcstr.c             |   51 ++++++++++++++++++++++++++++++++++++++++
 src/fcxml.c             |   22 ++++++++++++++++-
 10 files changed, 219 insertions(+), 63 deletions(-)

Adding an "easy" and "wip" patch stack

Robert Schwebel — 2011-11-07T08:45:07

Hi,

A next step we have agreed on is to add two example patch stacks, to
learn about the workflow:

1) an "easy" patch stack where we can quickly agree on
2) a more complicated one, which definitely needs some work.

Suggestions?

rsc

PS: The VM makes progress, but unfortunately we had some hardware issues
    with new RAM on the host server. Our administration team is working
    on this. However, it shouldn't slow down the progress, as we can use
    my git tree posted some days ago in the meantime.

Temporary git repo

Robert Schwebel — 2011-11-01T08:07:54

Hi,

In order to share the README, I've setup a temporary repository here:
http://git.pengutronix.de/?p=rsc/send-patches-org.git;a=summary

It will move to git.send-patches.org when the machine was set up.

rsc

Proposal for send-patches.org patch repository

Robert Schwebel — 2011-10-31T19:24:14

About the send-patches.org Patch Repository
-------------------------------------------

This repository contains patches for other open source projects which
are necessary to make them more cross-compiling friendly. The cross
build community has a long history of carrying patches arround, but
trust us - we do all hate them :-)

Help us make the upstream better and create more awareness for cross
compile issues!

- The send-patches.org team


Patch Guidelines
----------------

The following checklist should make it easier for you to find out if a
patch contains all necessary information:

[ ] Is the patch documented using the Linux kernel's "canonical patch"
    format [1]?

[ ] The patch must contain a subject line (like an email subject),
    stating clearly what the patch does. Example:

    makefile: fix cross compile issues

[ ] Check if the subject line is descriptive enough to understand the
    patch, even if you wouldn't already know what it does :) Add a
    descriptive text to the body if the subject alone isn't enough.

[ ] Document what the issue is that is being fixed. If the patch fixes
    a build error, add the error output. This makes it easier for
    other people to find our patch with their favourite serach engine.

[ ] Document why the patch is necessary. Especially if the patch fixes a
    cross compile speciality, not everyone in the open source community
    might be aware of the background


Signing Patches
---------------

With a line saying

Signed-off-by: Joe Hacker <joe-iOHc7L4DgpLFDiOEh+KS6A< at >public.gmane.org>

a contributor states that he is following the rules. We use the same
definition as the Linux kernel, which is re-printed here:

        Developer's Certificate of Origin 1.1

        By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
            indicated in the file; or

        (b) The contribution is based upon previous work that, to the best
            of my knowledge, is covered under an appropriate open source
            license and I have the right under that license to submit that
            work with modifications, whether created in whole or in part
            by me, under the same open source license (unless I am
            permitted to submit under a different license), as indicated
            in the file; or

        (c) The contribution was provided directly to me by some other
            person who certified (a), (b) or (c) and I have not modified
            it.

        (d) I understand and agree that this project and the contribution
            are public and that a record of the contribution (including all
            personal information I submit with it, including my sign-off) is
            maintained indefinitely and may be redistributed consistent with
            this project or the open source license(s) involved.

Note that not all upstream patches want to see Signed-off-by: lines. If
there is a clear indication that this line isn't wanted by a project's
upstream, we should avoid it as well.


Acks
----

If you agree with a patch, you might add your "Acked-by: <addr>" line.
The rules are like in the Linux kernel.


Usage in Cross Distributions
----------------------------

We use an additional tag that declares that the downstream build systems
of send-patches.org have agreed on this patch:

Used-in: <buildsystem>

where <buildsystem> can be one of the following (in alphabetical order):

Buildroot (http://www.buildroot.net)
Crosstool-NG (http://crosstool-ng.org)
PTXdist (http://www.ptxdist.org)

The Used-in: tag must only be given by one of the maintainers of the
buildsystems in question. Anyone who has write access to the
send-patches.org repository is allowed to give this tag for the
respective build system.

With the Used-in: tag, we would like to give a clear statement that this
patch is not only a random idea by any Joe Hacker from the other end of
the galaxy, but the joined oppinion of the major cross build systems out
there.


Send-patches.org Reference
--------------------------

When patches go upstream, they often end up in bug trackers and public
mailing list archives. In order to give a reference back to where this
patch comes from, the following tag may be used:

Send-patches-org: <url>

with <url> pointing to the gitweb location of the latest version of this
patch.


Patch Names
-----------

As the different build systems use different rules to sort the order of
the patches, we have agreed on using 4-digit numbered patch names (this
is for example what you get from 'git format-patch', but it is no
requirement to use this tool). Patch names end with ".patch". Example:

0001-fix-makefile.patch
0002-do-something-really-important.patch

Build systems might or might not have additional "series.<buildsystem>"
files to state which exact subset they use. These series files contain
one patch name per line, comment lines with a # as the first character
and no empty lines [2].


Upstream Status
---------------

The upstream status of a patch is documented with these tags:

Upstream-status: <pending, accepted, rejected>
Upstream-origin: <URL>
Upstream-comment: <comment>
Not-for-upstream: <comment>

The Not-for-upstream: tag shall only be given if either upstream is dead
or the problem is really a local hack where no proper fix is available.
Please try really, really hard to avoid this tag.


Directory Structure and Workflow
--------------------------------

The directory structure uses the name of the package plus it's version
number on the top level. The naming scheme follows the tarball
extraction naming scheme, for example:

libusb-1.0.8/

If the upstream tarball extracts only to a directory named after the
package name, the version shall be added with a dash.

Below the package directory, each involved build system may have it's
own subdirectory, for example:

libusb-1.0.8/ptxdist/

If the build system finds a subdirectory with it's name, it shall use
the patches found there. If such a subdirectory does not exist, the
package directory shall be used to look for patches.

These rules allow the following workflow:

- A build system creates a package directory with the name and version
  of a package it has patches for.
- The build system adds it's patches to a <buildsystem>/ directory and
  adds it's Used-in: tags.
- The patches can be discussed on the mailing lists and it is possible
  to collect further Acked-by: tags.
- If the patch series has evolved up to a point where more build systems
  agree on the patches, the whole series can be moved upwards, to the
  package directory.
- Packages who are not participating in a series can just avoid their
  Used-in: tags and use their <buildsystem>/ subdirectory.


autogen.sh Scripts
------------------

A package directory may contain a script called autogen.sh. If this
script is there, it is being run by the build system after the patch
series has been applied and before the "configure" stage runs. This
mechanism can for example be used to run the autotools.


Open Issues
-----------

- Strategy for stable vs. development
- It might be possible to autogenerate the Send-patches-org: URL by
  using commit-hooks.
- The package directory naming scheme probably needs to be formalized
  more deeply

[1] http://lxr.linux.no/#linux+v3.1/Documentation/SubmittingPatches#L472
[2] there are broken quilt versions which cannot cope with empty lines

Where I found a path for a M-501 Board?

Jorge Yesid Rios Ortiz — 2011-06-30T16:56:28

I have a little problem when i try to update my kernel version.
I have a M501 evaluation board kit:
CPU: ATMEL AT91RM9200, with MMU
Clock: 180MHz
SDRAM: 32MB (16MB user space)
Flash: 16MB (12MB user space)
USB Host: x2, USB 2.0 compliant

In this moment, I have 2.6.14-M5 version (it's very old, I Know) and I
need to upgrade it because I can't do to work a webcam on this board.

I tried update many times the linux's kernel and different versions of
kernels  (2.6.18, 2.6.20, 2.6.22, 2.6.24....2.6.38 ) and basically I
can't do it for these reasons:

1) the toolchains is very old (3.3.2 version). I download different
versions of ARM's toolchains (like code sourcery lite version
http://www.codesourcery.com/sgpp/lite/arm  and others more), this
toolchains isn't working for my embedded system.  I wrote to
Artila's support and they wrote to me: "this is the last toolchain for
your board, you must to use them"

2) On Artila's web-site, the "last kernel version" is 2.6.14-M5 kernel
version update to 2010. 

If you have some idea about how to compile a newer recent kernel's
version and/or toolchain for my board I appreciated Very much.


Jorge

[PATCH] xf86-input-tslib: add support for Xorg Input ABI12

Hector Oron — 2011-06-06T23:59:09

Hello,

  Frederic Wagner has written initial patch for adding support to
xf86-input-tslib for Xorg Input ABI 12.

  I have reworked the attached patch to apply against xf86-input-tslib
SVN r48.

  Is it OK to commit?

Kind regards,

[PATCH] Make docbook2man optional

Thomas Petazzoni — 2011-01-07T17:01:08

module-init-tools build currently fails if docbook2man is not
available on the build system. However, since docbook2man is only used
to build the documentation, it is not strictly necessary, and there
are cases (embedded Linux build systems) where it's really useful to
not have to build things such as docbook2man.

This patch has been present in Buildroot for quite some time
now :

 http://git.buildroot.net/buildroot/tree/package/module-init-tools/module-init-tools-3.11-add-manpages-config-option.patch

OpenEmbedded has a different hack to disable the build of
module-init-tools manpages:

 http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/module-init-tools/files/no_man_rebuild

PTXdist has yet another different hack to also disable the build of
module-init-tools manpages:

 http://git.pengutronix.de/?p=ptxdist.git;a=blob;f=rules/module-init-tools.make;h=0af89157a0bec221bf44e44a8e66f9be5c23190f;hb=HEAD#l41

The fix consists in adding an automake conditional variable
HAVE_DOCBOOKTOMAN, which is defined when docbook-to-man has been
found. This variable is used in the Makefile.am to enable or disable
the construction of the manpages.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8< at >public.gmane.org>
---
 Makefile.am  |    7 ++++++-
 configure.ac |    7 +++----
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 6f83c12..9438350 100644
--- a/Makefile.am
+++ b/Makefile.am
< at >< at > -39,7 +39,12 < at >< at > modindex_LDADD = $(LDADD) libmodtools.a
 MAN5 = modprobe.conf.5 modules.dep.5 depmod.conf.5 modprobe.d.5
 MAN8 = depmod.8 insmod.8 lsmod.8 rmmod.8 modprobe.8 modinfo.8
 SGML = $(addprefix doc/,  $(MAN5:%.5=%.sgml) $(MAN8:%.8=%.sgml))
-dist_man_MANS = $(MAN5) $(MAN8)
+
+if HAVE_DOCBOOKTOMAN
+MANPAGES  = $(MAN5) $(MAN8)
+endif
+dist_man_MANS = $(MANPAGES)
+
 # If they haven't overridden mandir, fix it (never /man!)
 mandir =$(shell if [ < at >mandir< at > = $(prefix)/man ]; then if [ $(prefix) = / ]; then echo /usr/share/man; else echo $(prefix)/share/man; fi; else echo < at >mandir< at >; fi)
 
diff --git a/configure.ac b/configure.ac
index 163148e..ab16c96 100644
--- a/configure.ac
+++ b/configure.ac
< at >< at > -29,13 +29,12 < at >< at > fi])
 AC_PROG_CC
 AC_PROG_RANLIB
 
-AC_CHECK_PROGS(DOCBOOKTOMAN, docbook-to-man docbook2man, [no],)
-if test x"$DOCBOOKTOMAN" = xno
+AC_CHECK_PROGS(DOCBOOKTOMAN, docbook-to-man docbook2man)
+if test x"$DOCBOOKTOMAN" = x
 then
 AC_MSG_WARN([docbook2man not found])
-# fail with a meaningfull error if $DOCBOOKTOMAN called by the makefile
-DOCBOOKTOMAN=docbook2man
 fi
+AM_CONDITIONAL([HAVE_DOCBOOKTOMAN], [test "x$DOCBOOKTOMAN" != "x"])
  
 # Delay adding the zlib_flags until after AC_PROG_CC, so we can distinguish
 # between a broken cc and a working cc but missing libz.a.

Current state of things

Michal Hrušecký — 2010-12-25T19:56:44

Hi,

I just want to ask, what is the current state of things? Is there
already some collaboration process defined? Is there something already
going on? I was just thinking that it might make sense to extend
collaboration even to non-embedded distributions...

---
   Michal Hrusecky <Michal.Hrusecky-stAJ6ESoqRxg9hUCZPvPmw< at >public.gmane.org>

[PATCH] add support for LDFLAGS, don't overwrite CFLAGS

Wolfram Sang — 2010-11-29T14:05:04

When cross compiling the linker can not find libz, this patch
adds the LDFLAGS variable to pass the linkerflags.

Based on earier work by Erwin Rol.

Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ< at >public.gmane.org>
Signed-off-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ< at >public.gmane.org>
---
 squashfs-tools/Makefile |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/squashfs-tools/Makefile b/squashfs-tools/Makefile
index f45d722..3a649ff 100644
--- a/squashfs-tools/Makefile
+++ b/squashfs-tools/Makefile
< at >< at > -100,7 +100,7 < at >< at > MKSQUASHFS_OBJS = mksquashfs.o read_fs.o sort.o swap.o pseudo.o compressor.o
 UNSQUASHFS_OBJS = unsquashfs.o unsquash-1.o unsquash-2.o unsquash-3.o \
 unsquash-4.o swap.o compressor.o
 
-CFLAGS = $(INCLUDEDIR) -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE \
+CFLAGS += $(INCLUDEDIR) -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE \
 -D_GNU_SOURCE -DCOMP_DEFAULT=\"$(COMP_DEFAULT)\"  -O2 -Wall
 
 LIBS =
< at >< at > -196,7 +196,7 < at >< at > endif
 all: mksquashfs unsquashfs
 
 mksquashfs: $(MKSQUASHFS_OBJS)
-$(CC) $(MKSQUASHFS_OBJS) -lpthread -lm $(LIBS) -o $< at >
+$(CC) $(MKSQUASHFS_OBJS) -lpthread -lm $(LIBS) $(LDFLAGS) -o $< at >
 
 mksquashfs.o: mksquashfs.c squashfs_fs.h mksquashfs.h global.h sort.h \
 squashfs_swap.h xattr.h
< at >< at > -216,7 +216,7 < at >< at > xattr.o: xattr.h
 read_xattrs.o: xattr.h
 
 unsquashfs: $(UNSQUASHFS_OBJS)
-$(CC) $(UNSQUASHFS_OBJS) -lpthread -lm $(LIBS) -o $< at >
+$(CC) $(UNSQUASHFS_OBJS) -lpthread -lm $(LIBS) $(LDFLAGS) -o $< at >
 
 unsquashfs.o: unsquashfs.h unsquashfs.c squashfs_fs.h squashfs_swap.h \
 squashfs_compat.h global.h xattr.h

New tslib might be coming...

Wolfram Sang — 2010-11-14T11:48:36

Hiya,

in case you didn't notice: tslib has an active upstream again and a new release
1.1 might be due soon. So, it is probably a good time to check your local
patch-stacks and clean it up :)

Regards,

   Wolfram

PS: more information here:
https://lists.berlios.de/pipermail/tslib-general/2010-November/thread.html

[PATCH] fix build with --disable-crypto

Peter Korsgaard — 2010-09-23T20:09:06

options.c is missing the definition for struct context when built with
--disable-crypto, as it then doesn't get pulled in through push.h,
leading to build errors like:

options.c: In function ‘parse_http_proxy_fallback’:
options.c:1474: error: dereferencing pointer to incomplete type
options.c:1477: error: dereferencing pointer to incomplete type
options.c:1478: error: dereferencing pointer to incomplete type

Fix it by including forward.h

Signed-off-by: Peter Korsgaard <jacmet< at >sunsite.dk>
---
 options.c |    1 +
 1 file changed, 1 insertion(+)

Index: openvpn-2.1.3/options.c
===================================================================
--- openvpn-2.1.3.orig/options.c
+++ openvpn-2.1.3/options.c
< at >< at > -29,6 +29,7 < at >< at >
 
 #include "syshead.h"
 
+#include "forward.h"
 #include "buffer.h"
 #include "error.h"
 #include "common.h"

"patch dragging" vs git

David Wuertele — 2010-06-25T17:35:31

I have a question about how you would use git to do what I call "patch
dragging".  Maybe there's a better term for it, but what I mean is when a new
third-party package is released, I look at the patches I have in the previous
version's patch dir, and "drag" only the appropriate patches to the new version's
patch dir.

The dragging process is usually very quick because the patches are small text
files.  In most cases, even though my patches have been sent to the third-party,
they have not been integrated, and dragging them forward to the new version
requires very little manual tweaking.

My question is how would you use git to accomplish this task.  I realize that
this is a merge operation, but I am only a novice git user, and I can not
visualize the workflow.

As an example, let's say I have thirdparty_package-1.1.tar.gz, and a directory
of patches that looks like this:

  thirdparty_package-1.1/functionality1/001_foo.patch
  thirdparty_package-1.1/functionality1/002_foo.patch
  thirdparty_package-1.1/bugfix1/001_bar.patch
  thirdparty_package-1.1/bugfix1/002_baz.patch
  thirdparty_package-1.1/bugfix2/004_glorph.patch
  thirdparty_package-1.1/bugfix2/005_squemj.patch

Then thirdparty_package-1.2.tar.gz is released, and I look through my 1.1.
patches and realize that I want to take functionality1 forward but not the
bugfixes.  So I execute:

  mkdir -p thirdparty_package-1.2
  cp -a thirdparty_package-1.1/functionality1 thirdparty_package-1.2

I do a build, and if the stars align (they often do), my patches will apply
without any manual tweaking.

I know you could achieve a similar workflow in git by using git-diff between
versions to get specific patches, but that seems very cumbersome to me
compared with my "patch dragging".  I suspect there is a much simpler way
to do this in git, by thinking of it as merges between versions as opposed to
generating patches, but I can not see it.

Dave

[PATCH] teach ncurses-config about sysroot

Robert Schwebel — 2010-06-24T12:37:31

From: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ< at >public.gmane.org>

This patch teaches ncursrs-config about sysroot

Signed-off-by: Marc Kleine-Buddde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ< at >public.gmane.org>
Signed-off-by: Robert Schwebel <rsc-bIcnvbaLZ9MEGnE8C9+IrQ< at >public.gmane.org>

---
 misc/ncurses-config.in |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: ncurses-5.7/misc/ncurses-config.in
===================================================================
--- ncurses-5.7.orig/misc/ncurses-config.in
+++ ncurses-5.7/misc/ncurses-config.in
< at >< at > -75,11 +75,11 < at >< at > while test $# -gt 0; do
 # compile/link
 --cflags)
 INCS=
-if test "${prefix}/include" != /usr/include ; then
-INCS="-I${prefix}/include"
+if test "${SYSROOT}${prefix}/include" != /usr/include ; then
+INCS="-I${SYSROOT}${prefix}/include"
 fi
 if test "< at >WITH_OVERWRITE< at >" != no ; then
-INCS="$INCS -I${prefix}/include/${THIS}"
+INCS="$INCS -I${SYSROOT}${prefix}/include/${THIS}"
 fi
 sed -e 's,^[ ]*,,' -e 's, [ ]*, ,g' -e 's,[ ]*$,,' <<-ENDECHO
 $INCS
< at >< at > -87,7 +87,7 < at >< at > ENDECHO
 ;;
 --libs)
 sed -e 's,^[ ]*,,' -e 's, [ ]*, ,g' -e 's,[ ]*$,,' <<-ENDECHO
--L${exec_prefix}/lib < at >EXTRA_LDFLAGS< at > -l${THIS} < at >LIBS< at >
+-L${SYSROOT}${exec_prefix}/lib < at >EXTRA_LDFLAGS< at > -l${THIS} < at >LIBS< at >
 ENDECHO
 ;;
 # identification

Is this ml appropriate for announcing new cross-compilerbuild systems?

David Wuertele — 2010-06-14T19:04:56

Howdy, just came across this ml.  Are build systems besides buildroot and ptx
welcome here?

I have a make-based system that I'm developing, which I named "Crossplex".
It is quite mature for mips and intel architectures, and it can build toolchains
and targets using glibc and uClibc.

I would love for Crossplex to join the party if it is welcome.
The website is crossplex.org.

Dave



_______________________________________________
crossdev mailing list

FYI: paper on oss-qm project

Enrico Weigelt — 2010-05-08T17:16:41

Hi folks,

i've written a little paper on the oss-qm project, which aims to
offload common QM works from invidual distros to an common place:

http://www.metux.de/download/oss-qm-project-2010050101.pdf

cu

FOSDEM slides online

Robert Schwebel — 2010-02-11T11:50:27

Hi,

the FOSDEM slides are now online:
http://www.send-patches.org/news/index.html

Thanks again to all participants!

Robert

A couple of comments after Fosdem and OpenWrt repositoryadding

Florian Fainelli — 2010-02-09T12:19:00

Hi,

Following our "Cross-build systems" meeting at Fosdem, I just subscribed to 
this list. I first got a couple of comments:

- the welcome message of the mailing-list is in German, might be worth 
translating it to english for non-german speakers

- can you please reference the OpenWrt packages repository [1] to the "Patch 
repositories" page?

We should probably setup a common patch repository which could be easily used 
by all of our projects as a reference. For instance one might have the 
following structure to let our projects directly checkout patches from the 
send-patches.org repository:

/packages/
/foo/<version 1>/bar.patch
/foo/<version 2>/foo.patch
/bar/<version 1>....
/toolchain/
/gcc/4.4.1/blah.patch

... and whatever you feel is suitable to be shared.

We proposed at Fosdem that we could have two teams of people at send-
patches.org to perform the following actions:

- one team which checks in the patches they maintain in a cross-build project 
to the send-patches.org repository
- another team which picks patches and submit them to the upstream project 
(package authors)

What do you guys think about this?

--
[1]: https://dev.openwrt.org/browser/packages/