gmane.comp.embedded.crossdev

Re: ptxdist-trunk-1329017471 (Main PTXdist Development Trunk) URL-Check vom Sun Feb 12 04:31:11 CET 2012 ()

Robert Schwebel — 2012-02-13T09:40:58

Dear zlib maintainers,

On Mon, Feb 13, 2012 at 10:18:45AM +0100, Juergen Beisert wrote:

Would it be possible that you leave the old versions at their place,
instead of removing them if a new version is available?

All cross build systems (like ptxdist, OpenEmbedded, yocto, buildroot,
OpenWRT etc) who try to download sources from upstream servers would
really love you for doing this :-)

rsc

Re: [PATCH] [PATCH] only include execinfo.h ifcrashtrace support is enabled

Peter Korsgaard — 2012-01-03T08:54:11

 Robert> On Mon, Jan 02, 2012 at 02:49:40PM +0100, Peter Korsgaard wrote:
 >> 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.

 Robert> But the patch just removes the include...?

It's already included below in a conditional:

#ifdef ENABLE_CRASHTRACE
#include <execinfo.h>
#endif

Re: [PATCH] [PATCH] only include execinfo.h if crashtrace support is enabled

Robert Schwebel — 2012-01-03T08:45:20

But the patch just removes the include...?

rsc

[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>

Re: Proposal for send-patches.org patch repository

Mike Frysinger — 2011-12-16T17:08:28

http://news.gmane.org/gmane.comp.embedded.crossdev
-mike

Re: Proposal for send-patches.org patch repository

Enrico Weigelt — 2011-12-16T16:51:16

* Robert Schwebel <r.schwebel-bIcnvbaLZ9MEGnE8C9+IrQ< at >public.gmane.org> schrieb:

Okay. Which were th arguments for against the git approach ?


cu

Re: Proposal for send-patches.org patch repository

Robert Schwebel — 2011-12-16T15:39:25

This has been discussed already, and nothing has changed.

rsc

Re: Proposal for send-patches.org patch repository

Enrico Weigelt — 2011-12-16T15:23:19

* Esben Haabendal <esben.haabendal-rjjw5hvvQKZaa/9Udqfwiw< at >public.gmane.org> schrieb:

Hi folks,


sorry for digging out this old thread again ...


At this point, I'd like to raise the question, why to use text-
based patches at all, instead of directly using git.


cu

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 b

Re: ppc32 TEXTREL fix for binutils-2.22

Peter Korsgaard — 2011-12-05T13:47:20

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

Thanks, added to buildroot.

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

Re: Adding an "easy" and "wip" patch stack

Esben Haabendal — 2011-11-28T09:55:45

Sounds fine to me, although personally I don't really care about such a
generalization, as I expect to handle each package and/or patch one at a
time.

/Esben

Re: Adding an "easy" and "wip" patch stack

Robert Schwebel — 2011-11-28T09:51:59

Ping...

rsc

Re: [PATCH 3/3] fc-cache: add a --root option

Michael Olbrich — 2011-11-08T15:18:29

I think the comment should contain a use-case, so that upstream understands
why this is necessary.


I don't think this should be 'const'. You should never change a const
variable.

Michael

[PATCH 3/3] fc-cache: add a --root option

Mike Frysinger — 2011-11-08T05:25:01

We have to add a few new helper options for setting/getting the config
root, and then hooking into the low level dir/file scanners to utilize
these new paths.

Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A< at >public.gmane.org>
---
 fc-cache/fc-cache.c     |   43 +++++++++++++++++++++++++++++++++----------
 fc-cache/fc-cache.sgml  |   11 ++++++++++-
 fontconfig/fontconfig.h |    9 +++++++++
 src/fccache.c           |   40 ++++++++++++++++++++++++++++++++++++----
 src/fccfg.c             |   30 ++++++++++++++++++++++++++++--
 src/fcdir.c             |   13 +++++++++++--
 src/fcfreetype.c        |   10 +++++++++-
 src/fcxml.c             |   22 ++++++++++++++++++++--
 8 files changed, 156 insertions(+), 22 deletions(-)

diff --git a/fc-cache/fc-cache.c b/fc-cache/fc-cache.c
index 64eb22a..b57c731 100644
--- a/fc-cache/fc-cache.c
+++ b/fc-cache/fc-cache.c
< at >< at > -69,6 +69,7 < at >< at >
 const struct option longopts[] = {
     {"force", 0, 0, 'f'},
     {"really-force", 0, 0, 'r'},
+    {"root", 1, 0, 'R'},
     {

[PATCH 2/3] FcStat: export for people to use

Mike Frysinger — 2011-11-08T05:25:00

The fc-cache code uses stat() directly, but we already have a FcStat
helper to workaround misc issues, so export it and convert fc-cache
over.  This will be even more important when we add --root support.

Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A< at >public.gmane.org>
---
 fc-cache/fc-cache.c     |    4 ++--
 fontconfig/fontconfig.h |    3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/fc-cache/fc-cache.c b/fc-cache/fc-cache.c
index 98039f7..64eb22a 100644
--- a/fc-cache/fc-cache.c
+++ b/fc-cache/fc-cache.c
< at >< at > -154,7 +154,7 < at >< at > scanDirs (FcStrList *list, FcConfig *config, FcBool force, FcBool really_force,
     continue;
 }
 
-if (stat ((char *) dir, &statb) == -1)
+if (FcStat (dir, &statb) == -1)
 {
     switch (errno) {
     case ENOENT:
< at >< at > -304,7 +304,7 < at >< at > cleanCacheDirectory (FcConfig *config, FcChar8 *dir, FcBool verbose)
 else
 {
     target_dir = FcCacheDir (cache);
-    if (stat ((char *) target_dir, &target_stat) < 0)
+    if (FcStat (target_dir, &targ

[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.

Re: Proposal for send-patches.org patch repository

Esben Haabendal — 2011-11-02T05:14:45

While in the nit-picking area, I didn't get why there was any reason to
have both <buildsys>/* and *.<buildsys>, I think it is fine.

/Esben

Re: Proposal for send-patches.org patch repository

Thomas Petazzoni — 2011-11-01T21:16:21

Robert,

(Resent due to missing list in Cc:)

Le Tue, 1 Nov 2011 21:46:38 +0100,
Robert Schwebel <r.schwebel< at >pengutronix.de> a écrit :


That part looks fine to me. I'm a bit concerned by the repository
becoming a huge pile of crap with only build-system specific patches.
But only time will tell if this will take this path, or if we'll manage
to clean up things as we go and make patches more generically useful.

Thomas