* [Buildroot] [git commit] neon: cleanup
From: Michael S. Zick @ 2011-10-11 11:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111011075632.11D3A8E2F8@busybox.osuosl.org>
On Tue October 11 2011, Peter Korsgaard wrote:
> #############################################################
> -NEON_VERSION:=0.29.6
> -NEON_SITE:=http://www.webdav.org/neon/
> -NEON_INSTALL_STAGING:=YES
> -NEON_CONF_OPT:=--without-gssapi --disable-rpath
> +NEON_VERSION= 0.29.6
>
Shouldn't there be one more space in the above to be consistent?
Mike
> +NEON_SITE = http://www.webdav.org/neon/
> +NEON_INSTALL_STAGING = YES
> +NEON_CONF_OPT = --without-gssapi --disable-rpath
>
^ permalink raw reply
* [Buildroot] [PATCH 2/2] New package: feh
From: yegorslists at googlemail.com @ 2011-10-11 10:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1318329151-9831-1-git-send-email-yegorslists@googlemail.com>
From: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
package/Config.in | 1 +
package/feh/Config.in | 12 ++++++++++++
package/feh/feh.mk | 22 ++++++++++++++++++++++
3 files changed, 35 insertions(+), 0 deletions(-)
create mode 100644 package/feh/Config.in
create mode 100644 package/feh/feh.mk
diff --git a/package/Config.in b/package/Config.in
index 7f82934..b39f41b 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -133,6 +133,7 @@ source "package/fluxbox/Config.in"
comment "X applications"
source "package/alsamixergui/Config.in"
source "package/docker/Config.in"
+source "package/feh/Config.in"
source "package/gqview/Config.in"
source "package/gmpc/Config.in"
source "package/gob2/Config.in"
diff --git a/package/feh/Config.in b/package/feh/Config.in
new file mode 100644
index 0000000..d462cba
--- /dev/null
+++ b/package/feh/Config.in
@@ -0,0 +1,12 @@
+config BR2_PACKAGE_FEH
+ bool "feh"
+ depends on BR2_PACKAGE_XLIB_LIBXINERAMA
+ depends on BR2_PACKAGE_XLIB_LIBXT
+ select BR2_PACKAGE_IMLIB2
+ select BR2_PACKAGE_IMLIB2_PNG
+ select BR2_PACKAGE_GIBLIB
+ select BR2_PACKAGE_LIBCURL
+ help
+ feh is an X11 image viewer aimed mostly at console users.
+
+ http://feh.finalrewind.org/
diff --git a/package/feh/feh.mk b/package/feh/feh.mk
new file mode 100644
index 0000000..b59bb2f
--- /dev/null
+++ b/package/feh/feh.mk
@@ -0,0 +1,22 @@
+FEH_VERSION = 2.0
+FEH_SOURCE = feh-$(FEH_VERSION).tar.bz2
+FEH_SITE = http://feh.finalrewind.org/
+FEH_DEPENDENCIES = libcurl giblib imlib2 libpng xlib_libXinerama xlib_libXt
+
+define FEH_BUILD_CMDS
+ $(MAKE1) CC="$(TARGET_CC) $(TARGET_CFLAGS) $(TARGET_LDFLAGS)" \
+ -C $(@D) all
+endef
+
+define FEH_INSTALL_TARGET_CMDS
+ $(MAKE1) CC="$(TARGET_CC) $(TARGET_CFLAGS) $(TARGET_LDFLAGS) " \
+ DESTDIR=$(TARGET_DIR) -C $(@D) install
+endef
+
+define FEH_UNINSTALL_TARGET_CMDS
+ $(MAKE1) CC="$(TARGET_CC) $(TARGET_CFLAGS) $(TARGET_LDFLAGS) " \
+ DESTDIR=$(TARGET_DIR) -C $(@D) uninstall
+endef
+
+$(eval $(call GENTARGETS))
+
--
1.7.1.1
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] New package: giblib
From: yegorslists at googlemail.com @ 2011-10-11 10:32 UTC (permalink / raw)
To: buildroot
From: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
package/Config.in | 1 +
package/giblib/Config.in | 8 ++++++++
package/giblib/giblib.mk | 15 +++++++++++++++
3 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 package/giblib/Config.in
create mode 100644 package/giblib/giblib.mk
diff --git a/package/Config.in b/package/Config.in
index 7a7b4bf..7f82934 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -280,6 +280,7 @@ source "package/cairo/Config.in"
source "package/fltk/Config.in"
source "package/fontconfig/Config.in"
source "package/freetype/Config.in"
+source "package/giblib/Config.in"
source "package/gtk2-engines/Config.in"
source "package/gtk2-themes/Config.in"
source "package/imlib2/Config.in"
diff --git a/package/giblib/Config.in b/package/giblib/Config.in
new file mode 100644
index 0000000..0c704e1
--- /dev/null
+++ b/package/giblib/Config.in
@@ -0,0 +1,8 @@
+config BR2_PACKAGE_GIBLIB
+ bool "giblib"
+ select BR2_PACKAGE_IMLIB2
+ help
+ Giblib is a simple library which wraps imlib2.
+
+ http://linuxbrit.co.uk/giblib/
+
diff --git a/package/giblib/giblib.mk b/package/giblib/giblib.mk
new file mode 100644
index 0000000..8a868c5
--- /dev/null
+++ b/package/giblib/giblib.mk
@@ -0,0 +1,15 @@
+#############################################################
+#
+# giblib
+#
+#############################################################
+GIBLIB_VERSION = 1.2.4
+GIBLIB_SOURCE = giblib-$(GIBLIB_VERSION).tar.gz
+GIBLIB_SITE = http://linuxbrit.co.uk/downloads/
+GIBLIB_INSTALL_STAGING = YES
+GIBLIB_DEPENDENCIES = imlib2
+GIBLIB_CONF_OPT = --with-imlib2-prefix=$(STAGING)/usr/lib \
+ --with-imlib2-exec-prefix=$(STAGING)/usr/bin
+
+$(eval $(call AUTOTARGETS))
+
--
1.7.1.1
^ permalink raw reply related
* [Buildroot] [PATCH v2] New package: ImLib2
From: yegorslists at googlemail.com @ 2011-10-11 10:26 UTC (permalink / raw)
To: buildroot
From: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Frederic Bassaler <frederic.bassaler@gmail.com>
Signed-off-by: Matias Garcia <mgarcia@rossvideo.com>
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
Changes v2: add libXext dependency
package/Config.in | 1 +
package/imlib2/Config.in | 38 +++++++++++++++++++++++++++++
package/imlib2/imlib2.mk | 60 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 package/imlib2/Config.in
create mode 100644 package/imlib2/imlib2.mk
diff --git a/package/Config.in b/package/Config.in
index 7dc8887..7a7b4bf 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -282,6 +282,7 @@ source "package/fontconfig/Config.in"
source "package/freetype/Config.in"
source "package/gtk2-engines/Config.in"
source "package/gtk2-themes/Config.in"
+source "package/imlib2/Config.in"
source "package/jpeg/Config.in"
source "package/libart/Config.in"
source "package/libdrm/Config.in"
diff --git a/package/imlib2/Config.in b/package/imlib2/Config.in
new file mode 100644
index 0000000..9b6ee98
--- /dev/null
+++ b/package/imlib2/Config.in
@@ -0,0 +1,38 @@
+config BR2_PACKAGE_IMLIB2
+ bool "imlib2"
+ help
+ Imlib 2 is the successor to Imlib.
+
+ http://freshmeat.net/projects/imlib2/
+
+if BR2_PACKAGE_IMLIB2
+
+config BR2_PACKAGE_IMLIB2_JPEG
+ select BR2_PACKAGE_JPEG
+ bool "JPEG support"
+
+config BR2_PACKAGE_IMLIB2_PNG
+ select BR2_PACKAGE_LIBPNG
+ bool "PNG support"
+
+config BR2_PACKAGE_IMLIB2_GIF
+ select BR2_PACKAGE_LIBUNGIF
+ bool "GIF support"
+
+config BR2_PACKAGE_IMLIB2_TIFF
+ select BR2_PACKAGE_TIFF
+ bool "TIFF support"
+
+config BR2_PACKAGE_IMLIB2_FREETYPE
+ select BR2_PACKAGE_FREETYPE
+ bool "FreeType support"
+
+config BR2_PACKAGE_IMLIB2_ID3
+ select BR2_PACKAGE_LIBID3TAG
+ bool "ID3 support"
+
+config BR2_PACKAGE_IMLIB2_X
+ select BR2_PACKAGE_XLIB_LIBX11
+ select BR2_PACKAGE_XLIB_LIBXEXT
+ bool "X support"
+endif
diff --git a/package/imlib2/imlib2.mk b/package/imlib2/imlib2.mk
new file mode 100644
index 0000000..5a274ee
--- /dev/null
+++ b/package/imlib2/imlib2.mk
@@ -0,0 +1,60 @@
+#############################################################
+#
+## IMLIB2
+#
+##############################################################
+IMLIB2_VERSION = 1.4.5
+IMLIB2_SOURCE = imlib2-$(IMLIB2_VERSION).tar.bz2
+IMLIB2_SITE = http://$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/project/enlightenment/imlib2-src/$(IMLIB2_VERSION)/
+IMLIB2_INSTALL_STAGING = YES
+IMLIB2_DEPENDENCIES = host-pkg-config
+
+ifeq ($(BR2_PACKAGE_IMLIB2_X),y)
+ IMLIB2_CONF_OPT += --with-x
+ IMLIB2_DEPENDENCIES += xlib_libX11 xlib_libXext
+endif
+
+ifeq ($(BR2_PACKAGE_IMLIB2_FREETYPE),y)
+ IMLIB2_CONF_OPT += --with-freetype-config=$(STAGING_DIR)/usr/bin/freetype-config
+ IMLIB2_DEPENDENCIES += freetype
+else
+ IMLIB2_CONF_OPT += --without-freetype
+endif
+
+ifeq ($(BR2_PACKAGE_IMLIB2_JPEG),y)
+ IMLIB2_CONF_OPT += --with-jpeg
+ IMLIB2_DEPENDENCIES += jpeg
+else
+ IMLIB2_CONF_OPT += --without-jpeg
+endif
+
+ifeq ($(BR2_PACKAGE_IMLIB2_PNG),y)
+ IMLIB2_CONF_OPT += --with-png
+ IMLIB2_DEPENDENCIES += libpng
+else
+ IMLIB2_CONF_OPT += --without-png
+endif
+
+ifeq ($(BR2_PACKAGE_IMLIB2_GIF),y)
+ IMLIB2_CONF_OPT += --with-gif
+ IMLIB2_DEPENDENCIES += libungif
+else
+ IMLIB2_CONF_OPT += --without-gif
+endif
+
+ifeq ($(BR2_PACKAGE_IMLIB2_TIFF),y)
+ IMLIB2_CONF_OPT += --with-tiff
+ IMLIB2_DEPENDENCIES += tiff
+else
+ IMLIB2_CONF_OPT += --without-tiff
+endif
+
+ifeq ($(BR2_PACKAGE_IMLIB2_ID3),y)
+ IMLIB2_CONF_OPT += --with-id3
+ IMLIB2_DEPENDENCIES += libid3tag
+else
+ IMLIB2_CONF_OPT += --without-id3
+endif
+
+$(eval $(call AUTOTARGETS))
+
--
1.7.1.1
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] package: instrument to gather timing data
From: Thomas De Schampheleire @ 2011-10-11 8:29 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201110110759.23066.arnout@mind.be>
Hi,
On Tue, Oct 11, 2011 at 7:59 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>
> On Sunday 09 October 2011 18:17:27, Thomas Petazzoni wrote:
>
>> Instrument the package infrastructure to generate a
>
>> $(O)/build-time.data file which contains one line for each step of
>
>> each package and the corresponding duration in milliseconds.
>
>>
>
>> The instrumentation is not perfect yet, as it doesn't account for
>
>> packages with overriden source directory
>
> Why is that relevant? The output goes to $(O) anyway. But this makes me
> think: wouldn't it be better to
>
>> and the build-time.data is
>
>> never removed, so results will accumulate if several partial builds
>
>> are done.
>
> I would call that a feature :-) Partial builds typically mean that you're
> hacking away at some package, and then it's very relevant to see the impact
> on build time.
How would you see the impact? Wouldn't it be more useful to save the
timing data for subsequent runs in different files (e.g. timestamped
files) so that you can compare such runs?
If you let the data accumulate, you'd get one big number for each
step/package combination, unless you're going to update the parser
script to display the different data lines as separate entities, one
for each run).
>
> Of course, there would need to be a target buildtime-clean that removes the
> files.
>
>>
>
>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
>> ---
>
>> package/Makefile.package.in | 28 ++++++++++++++++++++++++++++
>
>> 1 files changed, 28 insertions(+), 0 deletions(-)
>
>>
>
>> diff --git a/package/Makefile.package.in b/package/Makefile.package.in
>
>> index b5ef57b..605b518 100644
>
>> --- a/package/Makefile.package.in
>
>> +++ b/package/Makefile.package.in
>
>> @@ -254,6 +254,18 @@ define sep
>
>>
>
>> endef
>
>>
>
>> +define savetime
>
>> + echo $$(($$(date +%s%N)/1000000)) > $(O)/.br.time
>
>> +endef
>
>> +
>
>> +define outputtime
>
>> + newtime=`echo $$(($$(date +%s%N)/1000000))` ; \
>
>> + oldtime=`cat $(O)/.br.time` ; \
>
>> + rm -f .br.time ; \
>
>> + timediff=$$(($$newtime-$$oldtime)) ; \
>
>> + echo "$(1),$(2),$$timediff" >> $(O)/build-time.data
>
> Is there a particular reason to use a make function parameter in a place
> like this instead of using $($(PKG)_NAME) directly? I've seen this in other
> places in buildroot as well...
>
> [snip]
>
> 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: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
^ permalink raw reply
* [Buildroot] [Bug 4231] libneon.so: undefined reference to `SSL_SESSION_cmp'
From: bugzilla at busybox.net @ 2011-10-11 7:56 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-4231-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=4231
Peter Korsgaard <jacmet@uclibc.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Peter Korsgaard <jacmet@uclibc.org> ---
Fixed in git by updating libneon package (8ece8e2775cb18987)
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [git commit] rpm: only show xz dependency comment if enabled
From: Peter Korsgaard @ 2011-10-11 7:55 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=f35348c3f6435e7e1a420fb07b335c1fd110aa46
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/rpm/Config.in | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/package/rpm/Config.in b/package/rpm/Config.in
index 8d4c6a3..a80a5a7 100644
--- a/package/rpm/Config.in
+++ b/package/rpm/Config.in
@@ -15,16 +15,16 @@ config BR2_PACKAGE_RPM
http://rpm5.org
+if BR2_PACKAGE_RPM
+
config BR2_PACKAGE_RPM_BZIP2_PAYLOADS
bool "support for bzip2 payloads"
- depends on BR2_PACKAGE_RPM
select BR2_PACKAGE_BZIP2
help
Support for bzip2 payloads in RPM.
config BR2_PACKAGE_RPM_XZ_PAYLOADS
bool "support for xz payloads"
- depends on BR2_PACKAGE_RPM
depends on BR2_INSTALL_LIBSTDCPP
help
Support for xz payloads in RPM.
@@ -32,4 +32,6 @@ config BR2_PACKAGE_RPM_XZ_PAYLOADS
comment "xz payload support requires a toolchain with c++ support"
depends on !BR2_INSTALL_LIBSTDCPP
+endif
+
^ permalink raw reply related
* [Buildroot] [git commit] neon: default to xml support if dependencies are available
From: Peter Korsgaard @ 2011-10-11 7:55 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=da653dd4ea233aeaf314f8784c5312b6472a2a2a
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Use expat support if expat package is enabled, libxml2 if enabled and
otherwise noxml.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/neon/Config.in | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/package/neon/Config.in b/package/neon/Config.in
index 5ebd64d..53cc8f5 100644
--- a/package/neon/Config.in
+++ b/package/neon/Config.in
@@ -21,7 +21,6 @@ config BR2_PACKAGE_NEON_SSL
choice
prompt "XML Support"
- default BR2_PACKAGE_NEON_NOXML
depends on BR2_PACKAGE_NEON
help
Select which XML library to use...
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] package: instrument to gather timing data
From: Thomas Petazzoni @ 2011-10-11 7:34 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201110110759.23066.arnout@mind.be>
Le Tue, 11 Oct 2011 07:59:22 +0200,
Arnout Vandecappelle <arnout@mind.be> a ?crit :
> On Sunday 09 October 2011 18:17:27, Thomas Petazzoni wrote:
> > Instrument the package infrastructure to generate a
> > $(O)/build-time.data file which contains one line for each step of
> > each package and the corresponding duration in milliseconds.
> >
> > The instrumentation is not perfect yet, as it doesn't account for
> > packages with overriden source directory
>
> Why is that relevant?
With an overidden source directory, the step of steps are different:
instead of download, extract, patch, configure, etc., it's rsync,
configure, etc.
> The output goes to $(O) anyway. But this makes me
> think: wouldn't it be better to
To ? :-)
> I would call that a feature :-) Partial builds typically mean that you're
> hacking away at some package, and then it's very relevant to see the impact on
> build time.
Ok.
> Of course, there would need to be a target buildtime-clean that removes the
> files.
Why not, yes.
> > +define outputtime
> > + newtime=`echo $$(($$(date +%s%N)/1000000))` ; \
> > + oldtime=`cat $(O)/.br.time` ; \
> > + rm -f .br.time ; \
> > + timediff=$$(($$newtime-$$oldtime)) ; \
> > + echo "$(1),$(2),$$timediff" >> $(O)/build-time.data
>
> Is there a particular reason to use a make function parameter in a place like
> this instead of using $($(PKG)_NAME) directly? I've seen this in other places
> in buildroot as well...
No, I guess I could use $($(PKG)_NAME) directly.
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] [git commit] neon: cleanup
From: Peter Korsgaard @ 2011-10-11 7:27 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=66e09abc57f88bfea7bebd50b9dff7d56e99689e
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Whitespace fixes / removal of redundant lines. No functional change.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/neon/neon.mk | 55 ++++++++++++++++++++++++-------------------------
1 files changed, 27 insertions(+), 28 deletions(-)
diff --git a/package/neon/neon.mk b/package/neon/neon.mk
index 95664d7..272d5e0 100644
--- a/package/neon/neon.mk
+++ b/package/neon/neon.mk
@@ -3,46 +3,45 @@
# neon
#
#############################################################
-NEON_VERSION:=0.29.6
-NEON_SITE:=http://www.webdav.org/neon/
-NEON_INSTALL_STAGING:=YES
-NEON_CONF_OPT:=--without-gssapi --disable-rpath
+NEON_VERSION= 0.29.6
+NEON_SITE = http://www.webdav.org/neon/
+NEON_INSTALL_STAGING = YES
+NEON_CONF_OPT = --without-gssapi --disable-rpath
-NEON_DEPENDENCIES:=host-pkg-config
+NEON_DEPENDENCIES = host-pkg-config
-ifeq ($(BR2_PACKAGE_NEON_LIBXML2),y)
-NEON_CONF_OPT+=--with-libxml2=yes
-NEON_CONF_OPT+=--with-expat=no
-NEON_CONF_ENV+=ac_cv_prog_XML2_CONFIG=$(STAGING_DIR)/usr/bin/xml2-config
-NEON_DEPENDENCIES+=libxml2
-endif
ifeq ($(BR2_PACKAGE_NEON_ZLIB),y)
-NEON_CONF_OPT+=--with-zlib=$(STAGING_DIR)
-NEON_DEPENDENCIES+=zlib
+NEON_CONF_OPT += --with-zlib=$(STAGING_DIR)
+NEON_DEPENDENCIES += zlib
else
-NEON_CONF_OPT+=--without-zlib
+NEON_CONF_OPT += --without-zlib
endif
+
ifeq ($(BR2_PACKAGE_NEON_SSL),y)
-NEON_CONF_OPT+=--with-ssl
-NEON_DEPENDENCIES+=openssl
+NEON_CONF_OPT += --with-ssl
+NEON_DEPENDENCIES += openssl
else
-NEON_CONF_OPT+=--without-ssl
+NEON_CONF_OPT += --without-ssl
endif
+
ifeq ($(BR2_PACKAGE_NEON_EXPAT),y)
-NEON_CONF_OPT+=--with-expat=$(STAGING_DIR)/usr/lib/libexpat.la
-NEON_CONF_OPT+=--with-libxml2=no
-NEON_DEPENDENCIES+=expat
-endif
-ifeq ($(BR2_PACKAGE_NEON_NOXML),y)
-# webdav needs xml support
-NEON_CONF_OPT+=--disable-webdav
+NEON_CONF_OPT += --with-expat=$(STAGING_DIR)/usr/lib/libexpat.la
+NEON_DEPENDENCIES += expat
+else
+NEON_CONF_OPT += --with-expat=no
endif
-ifeq ($(BR2_PACKAGE_OPENSSL),y)
-NEON_CONF_OPT+=--with-ssl
-NEON_DEPENDENCIES+=openssl
+ifeq ($(BR2_PACKAGE_NEON_LIBXML2),y)
+NEON_CONF_OPT += --with-libxml2=yes
+NEON_CONF_ENV += ac_cv_prog_XML2_CONFIG=$(STAGING_DIR)/usr/bin/xml2-config
+NEON_DEPENDENCIES += libxml2
else
-NEON_CONF_OPT+=--without-ssl
+NEON_CONF_OPT += --with-libxml2=no
+endif
+
+ifeq ($(BR2_PACKAGE_NEON_NOXML),y)
+# webdav needs xml support
+NEON_CONF_OPT += --disable-webdav
endif
define NEON_REMOVE_CONFIG_SCRIPTS
^ permalink raw reply related
* [Buildroot] [git commit] neon: bump version
From: Peter Korsgaard @ 2011-10-11 7:11 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=8ece8e2775cb189874a0e490934cea2f39dbb734
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Closes #4321
Old neon version wasn't compatible with our openssl version, so bump
the version. This also fixes some security related bugs.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
CHANGES | 3 ++-
package/neon/neon.mk | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/CHANGES b/CHANGES
index 6345210..cac5053 100644
--- a/CHANGES
+++ b/CHANGES
@@ -32,7 +32,7 @@
libevent, libglib2, libiconv, libreplaygain, libroxml,
libsamplerate, libsndfile, libsoup, libsvgtiny, libtool,
lighttpd, linux-fusion, lite, lsof, lzo, lzop, mcookie,
- mpg123, mpd, mpfr, musepack, mysql_client, ncurses, netcat,
+ mpg123, mpd, mpfr, musepack, mysql_client, ncurses, neon, netcat,
netsnmp, ntfs-3g, ntfsprogs, openssh, openssl, python, qt,
radvd, rsync, samba, sawman, sdl_sound, smartmontools, sqlite,
squid, sylpheed, taglib, tar, tcpreplay, tslib, usbutils,
@@ -63,6 +63,7 @@
#4165: lrzsz-fix-symlink-at-rebuild.patch
#4171: makedevs-unused-but-set-variable.patch
#4183: Codesourcery toolchain download site has changed
+ #4231: libneon.so: undefined reference to `SSL_SESSION_cmp'
2011.08, Released August 31th, 2011:
diff --git a/package/neon/neon.mk b/package/neon/neon.mk
index 4e17188..95664d7 100644
--- a/package/neon/neon.mk
+++ b/package/neon/neon.mk
@@ -3,7 +3,7 @@
# neon
#
#############################################################
-NEON_VERSION:=0.28.3
+NEON_VERSION:=0.29.6
NEON_SITE:=http://www.webdav.org/neon/
NEON_INSTALL_STAGING:=YES
NEON_CONF_OPT:=--without-gssapi --disable-rpath
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] package: instrument to gather timing data
From: Arnout Vandecappelle @ 2011-10-11 5:59 UTC (permalink / raw)
To: buildroot
In-Reply-To: <0cbf021419332c37bd77e661c97cfc881329f1bb.1318176666.git.thomas.petazzoni@free-electrons.com>
On Sunday 09 October 2011 18:17:27, Thomas Petazzoni wrote:
> Instrument the package infrastructure to generate a
> $(O)/build-time.data file which contains one line for each step of
> each package and the corresponding duration in milliseconds.
>
> The instrumentation is not perfect yet, as it doesn't account for
> packages with overriden source directory
Why is that relevant? The output goes to $(O) anyway. But this makes me
think: wouldn't it be better to
> and the build-time.data is
> never removed, so results will accumulate if several partial builds
> are done.
I would call that a feature :-) Partial builds typically mean that you're
hacking away at some package, and then it's very relevant to see the impact on
build time.
Of course, there would need to be a target buildtime-clean that removes the
files.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> package/Makefile.package.in | 28 ++++++++++++++++++++++++++++
> 1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/package/Makefile.package.in b/package/Makefile.package.in
> index b5ef57b..605b518 100644
> --- a/package/Makefile.package.in
> +++ b/package/Makefile.package.in
> @@ -254,6 +254,18 @@ define sep
>
> endef
>
> +define savetime
> + echo $$(($$(date +%s%N)/1000000)) > $(O)/.br.time
> +endef
> +
> +define outputtime
> + newtime=`echo $$(($$(date +%s%N)/1000000))` ; \
> + oldtime=`cat $(O)/.br.time` ; \
> + rm -f .br.time ; \
> + timediff=$$(($$newtime-$$oldtime)) ; \
> + echo "$(1),$(2),$$timediff" >> $(O)/build-time.data
Is there a particular reason to use a make function parameter in a place like
this instead of using $($(PKG)_NAME) directly? I've seen this in other places
in buildroot as well...
[snip]
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: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111011/018079a2/attachment-0001.html>
^ permalink raw reply
* [Buildroot] [PATCH 1/2] package: instrument to gather timing data
From: Arnout Vandecappelle @ 2011-10-11 5:59 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAAXf6LWG8Fhi-+UMi7f2yq4mZLhMvgxSPNVcttF-ErR_q+dwUA@mail.gmail.com>
On Monday 10 October 2011 15:41:28, Thomas De Schampheleire wrote:
> And what about making this behavior selectable, i.e. only if a certain
> config option is set, will data be gathered. In the other case,
> 'savetime' and 'outputtime' can be empty functions.
I think the runtime overhead is minimal, so there isn't much reason to
disable them. And you anyway still have the $(call) overhead for each target.
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: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111011/b9122932/attachment.html>
^ permalink raw reply
* [Buildroot] help needed on bringing up mips based system using buildroot
From: Ramana @ 2011-10-11 0:25 UTC (permalink / raw)
To: buildroot
Hi,
I am trying to bring up a mips based board (broadcom BCM91250A (SWARM))
and running into a wall. It complains about 'initrd' not found. how do I
link a ramdisk like initrd into the kernel that is being built.
I am using the 'make menuconfig' to configure the setup for the kernel
and can send the .config if needed.
Any help in this regard is greatly appreciated.
here is the boot log from the system
[RUN!]
Initializing cgroup subsys cpuset
Linux version 2.6.38.7 (root at merica) (gcc version 4.3.5 (Buildroot
2011.05) ) #4
SMP Wed Oct 5 10:44:45 PDT 2011
bootconsole [early0] enabled
CPU revision is: 00040103 (SiByte SB1)
FPU revision is: 000f0103
Checking for the multiply/shift bug... no.
Checking for the daddiu bug... no.
Broadcom SiByte BCM1125H A4 @ 800 MHz (SB1 rev 3)
Board type: SiByte BCM91250A (SWARM)
Determined physical RAM map:
memory: 0000000007e97e00 @ 0000000000000000 (usable)
Initrd not found or empty - disabling initrd
Zone PFN ranges:
DMA32 0x00000000 -> 0x00100000
Normal empty
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00007e97
Detected 0 available secondary CPU(s)
PERCPU: Embedded 10 pages/cpu @a8000000011c3000 s11232 r8192 d21536
u40960
Built 1 zonelists in Zone order, mobility grouping on. Total pages:
31963
Kernel command line: root=/dev/ram0 rw
PID hash table entries: 512 (order: 0, 4096 bytes)
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Primary instruction cache 32kB, VIVT, 4-way, linesize 32 bytes.
Primary data cache 32kB, 4-way, PIPT, no aliases, linesize 32 bytes
Memory: 122168k/129628k available (3065k kernel code, 7460k reserved,
922k data,
208k init, 0k highmem)
Hierarchical RCU
implementation.es;::xGhtrs;rG(sJ]xGhtrs;rG(Sk`Lxzqa`tA028pCcKtK
Regards,
Ramana Pureti
<DIV><FONT size="1">
E-mail confidentiality.
--------------------------------
This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.
Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677
Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Or if within the US,
Spirent Communications,
26750 Agoura Road, Calabasas, CA, 91302, USA.
Tel No. 1-818-676- 2300
</FONT></DIV>
^ permalink raw reply
* [Buildroot] [PATCH] add package tango-icon-theme and dependency icon-naming-utils
From: Klaus Schwarzkopf @ 2011-10-10 18:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111010193854.0ac757c6@skate>
Hi Thomas,
thanks very much.
Regards,
Klaus
Am 10.10.2011 19:38, schrieb Thomas Petazzoni:
> Le Mon, 10 Oct 2011 19:32:13 +0200,
> Klaus Schwarzkopf<schwarzkopf@sensortherm.de> a ?crit :
>
>> make: *** No rule to make target `host-icon-naming-utils', needed by
>> `tango-icon-theme-depends'. Stop.
>>
>> Can you help?
>
> Yes, see below.
>
>>> We usually have one patch per new package.
>>>
>>>> +$(eval $(call AUTOTARGETS,package,icon-naming-utils,host))
>>>
>>> This should be:
>>>
>>> $(eval $(call AUTOTARGETS))
>
> I should have said:
>
> $(eval $(call AUTOTARGETS,host))
>
> i.e, only the second and third argument have been removed. The optional
> fourth argument, which says whether we instantiate a host or target
> package, remains. Its default value is "target", so with just $(eval
> $(call AUTOTARGETS)) you create a target package and not the host
> package.
>
> Sorry for the mistake.
>
> Thomas
^ permalink raw reply
* [Buildroot] [PATCH 2/2 v2] icon-naming-utils for tango-icon-theme
From: Klaus Schwarzkopf @ 2011-10-10 18:08 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1318253496-23729-1-git-send-email-schwarzkopf@sensortherm.de>
---
package/icon-naming-utils/icon-naming-utils.mk | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
create mode 100644 package/icon-naming-utils/icon-naming-utils.mk
diff --git a/package/icon-naming-utils/icon-naming-utils.mk b/package/icon-naming-utils/icon-naming-utils.mk
new file mode 100644
index 0000000..1ac359a
--- /dev/null
+++ b/package/icon-naming-utils/icon-naming-utils.mk
@@ -0,0 +1,11 @@
+#############################################################
+#
+# icon-naming-utils
+#
+#############################################################
+ICON_NAMING_UTILS_VERSION = 0.8.90
+ICON_NAMING_UTILS_SOURCE = icon-naming-utils-$(ICON_NAMING_UTILS_VERSION).tar.gz
+ICON_NAMING_UTILS_SITE = http://tango.freedesktop.org/releases/
+HOST_ICON_NAMING_UTILS_CONF_OPT = --datarootdir=$(HOST_DIR)/usr/lib
+
+$(eval $(call AUTOTARGETS,host))
--
1.7.0.4
^ permalink raw reply related
* [Buildroot] [PATCH 1/2 v2] add package tango-icon-theme
From: Klaus Schwarzkopf @ 2011-10-10 18:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1318253496-23729-1-git-send-email-schwarzkopf@sensortherm.de>
This package need icon-naming-utils.
Signed-off-by: Klaus Schwarzkopf <schwarzkopf@sensortherm.de>
---
package/Config.in | 1 +
package/tango-icon-theme/Config.in | 6 ++++++
package/tango-icon-theme/tango-icon-theme.mk | 15 +++++++++++++++
3 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 package/tango-icon-theme/Config.in
create mode 100644 package/tango-icon-theme/tango-icon-theme.mk
diff --git a/package/Config.in b/package/Config.in
index 7dc8887..1cc953c 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -115,6 +115,7 @@ source "package/sdl_sound/Config.in"
source "package/sdl_net/Config.in"
source "package/sdl_ttf/Config.in"
source "package/sdl_gfx/Config.in"
+source "package/tango-icon-theme/Config.in"
comment "other GUIs"
source "package/qt/Config.in"
diff --git a/package/tango-icon-theme/Config.in b/package/tango-icon-theme/Config.in
new file mode 100644
index 0000000..cf20e9b
--- /dev/null
+++ b/package/tango-icon-theme/Config.in
@@ -0,0 +1,6 @@
+config BR2_PACKAGE_TANGO_ICON_THEME
+ bool "tango icon theme"
+ help
+ Icons from the tango desktop project.
+
+ http://tango.freedesktop.org/Tango_Desktop_Project
diff --git a/package/tango-icon-theme/tango-icon-theme.mk b/package/tango-icon-theme/tango-icon-theme.mk
new file mode 100644
index 0000000..2c1a5a5
--- /dev/null
+++ b/package/tango-icon-theme/tango-icon-theme.mk
@@ -0,0 +1,15 @@
+#############################################################
+#
+# tango-icon-theme
+#
+#############################################################
+TANGO_ICON_THEME_VERSION = 0.8.90
+TANGO_ICON_THEME_SOURCE = tango-icon-theme-$(TANGO_ICON_THEME_VERSION).tar.gz
+TANGO_ICON_THEME_SITE = http://tango.freedesktop.org/releases/
+
+TANGO_ICON_THEME_CONF_ENV = PKG_CONFIG_PATH=$(HOST_DIR)/usr/lib/pkgconfig
+TANGO_ICON_THEME_CONF_OPT = --disable-icon-framing
+
+TANGO_ICON_THEME_DEPENDENCIES = host-icon-naming-utils host-pkg-config
+
+$(eval $(call AUTOTARGETS))
--
1.7.0.4
^ permalink raw reply related
* [Buildroot] [PATCH] add package tango-icon-theme and dependency icon-naming-utils
From: Thomas Petazzoni @ 2011-10-10 17:38 UTC (permalink / raw)
To: buildroot
In-Reply-To: <4E932C1D.1090605@sensortherm.de>
Le Mon, 10 Oct 2011 19:32:13 +0200,
Klaus Schwarzkopf <schwarzkopf@sensortherm.de> a ?crit :
> make: *** No rule to make target `host-icon-naming-utils', needed by
> `tango-icon-theme-depends'. Stop.
>
> Can you help?
Yes, see below.
> > We usually have one patch per new package.
> >
> >> +$(eval $(call AUTOTARGETS,package,icon-naming-utils,host))
> >
> > This should be:
> >
> > $(eval $(call AUTOTARGETS))
I should have said:
$(eval $(call AUTOTARGETS,host))
i.e, only the second and third argument have been removed. The optional
fourth argument, which says whether we instantiate a host or target
package, remains. Its default value is "target", so with just $(eval
$(call AUTOTARGETS)) you create a target package and not the host
package.
Sorry for the mistake.
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] add package tango-icon-theme and dependency icon-naming-utils
From: Klaus Schwarzkopf @ 2011-10-10 17:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111010161008.3ba4b436@skate>
Hello Thomas,
if made the changes, and test it with the latest git tree. But i get an
error:
>>> tango-icon-theme 0.8.90 Extracting
gzip -d -c
/home/klaus/ti-dvsdk_dm365/buildroot/dl/tango-icon-theme-0.8.90.tar.gz |
tar --strip-components=1 -C
/home/klaus/ti-dvsdk_dm365/buildroot/output/build/tango-icon-theme-0.8.90
-xf -
>>> tango-icon-theme 0.8.90 Patching package//tango-icon-theme
>>> tango-icon-theme 0.8.90 Updating config.sub and config.guess
for file in config.guess config.sub; do for i in $(find
/home/klaus/ti-dvsdk_dm365/buildroot/output/build/tango-icon-theme-0.8.90 -name
$file); do cp support/gnuconfig/$file $i; done; done
>>> tango-icon-theme 0.8.90 Patching libtool
make: *** No rule to make target `host-icon-naming-utils', needed by
`tango-icon-theme-depends'. Stop.
Can you help?
Regards,
Klaus
Am 10.10.2011 16:10, schrieb Thomas Petazzoni:
> Hello Klaus,
>
> Le Mon, 10 Oct 2011 15:31:36 +0200,
> Klaus Schwarzkopf<schwarzkopf@sensortherm.de> a ?crit :
>
>> Signed-off-by: Klaus Schwarzkopf<schwarzkopf@sensortherm.de>
>> ---
>> package/Config.in | 1 +
>> package/icon-naming-utils/icon-naming-utils.mk | 11 +++++++++++
>> package/tango-icon-theme/Config.in | 6 ++++++
>> package/tango-icon-theme/tango-icon-theme.mk | 15 +++++++++++++++
>
> We usually have one patch per new package.
>
>> +$(eval $(call AUTOTARGETS,package,icon-naming-utils,host))
>
> This should be:
>
> $(eval $(call AUTOTARGETS))
>
> in the Git version of Buildroot. The documentation has not yet been
> updated in that regard.
>
>> +TANGO_ICON_THEME_VERSION = 0.8.90
>> +TANGO_ICON_THEME_SOURCE = tango-icon-theme-$(TANGO_ICON_THEME_VERSION).tar.gz
>> +TANGO_ICON_THEME_SITE = http://tango.freedesktop.org/releases/
>> +
>> +TANGO_ICON_THEME_CONF_ENV = PKG_CONFIG_PATH=$(HOST_DIR)/usr/lib/pkgconfig
>
> Here you're going to build a target package (tango-icon-theme) based on
> library informations of the host. This looks wrong. pkg-config already
> looks in $(STAGING_DIR)/usr/lib/pkgconfig.
>
> Could you detail why this is needed ?
>
>> +$(eval $(call AUTOTARGETS,package,tango-icon-theme))
>
> $(eval $(call AUTOTARGETS))
>
> Regards,
>
> Thomas
^ permalink raw reply
* [Buildroot] [PATCH 9/9] toolchain: speed up sysroot lib copying
From: Mike Frysinger @ 2011-10-10 15:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111010172952.77ba7d69@skate>
On Monday 10 October 2011 11:29:52 Thomas Petazzoni wrote:
> Le Mon, 10 Oct 2011 11:22:48 -0400, Mike Frysinger a ?crit :
> > yes & no. it's supposed to be here:
> > http://blackfin.uclinux.org/git/?p=buildroot
> >
> > but it seems they haven't published their internal development tree yet,
> > and i obviously cannot do that for them
>
> Ok, too bad. Is there a way for us to have a contact in this team, so
> we can tell our interest in seeing their developments merged upstream?
uclinux-dist-devel at blackfin.uclinux.org is the general development mailing list
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111010/5a3c4b41/attachment-0001.asc>
^ permalink raw reply
* [Buildroot] [PATCH 9/9] toolchain: speed up sysroot lib copying
From: Thomas Petazzoni @ 2011-10-10 15:29 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201110101122.49584.vapier@gentoo.org>
Le Mon, 10 Oct 2011 11:22:48 -0400,
Mike Frysinger <vapier@gentoo.org> a ?crit :
> yes & no. it's supposed to be here:
> http://blackfin.uclinux.org/git/?p=buildroot
>
> but it seems they haven't published their internal development tree yet, and i
> obviously cannot do that for them
Ok, too bad. Is there a way for us to have a contact in this team, so
we can tell our interest in seeing their developments merged upstream?
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 9/9] toolchain: speed up sysroot lib copying
From: Mike Frysinger @ 2011-10-10 15:22 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111010171919.268be9d6@skate>
On Monday 10 October 2011 11:19:19 Thomas Petazzoni wrote:
> Le Mon, 10 Oct 2011 11:12:16 -0400, Mike Frysinger a ?crit :
> > the people who still do are using buildroot for Blackfin, but sadly, they
> > were (are?) not as active as i in pushing upstream
>
> Ah, that's a shame, because your contributions were very interesting.
> Do those people have a public tree where we can follow their
> development and possibly upstream some of it ?
yes & no. it's supposed to be here:
http://blackfin.uclinux.org/git/?p=buildroot
but it seems they haven't published their internal development tree yet, and i
obviously cannot do that for them
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111010/cae6714b/attachment.asc>
^ permalink raw reply
* [Buildroot] [RFC] Build time graph generation
From: Thomas De Schampheleire @ 2011-10-10 15:19 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111010162016.55214e4e@skate>
On Mon, Oct 10, 2011 at 4:20 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Thomas,
>
> Le Mon, 10 Oct 2011 15:55:49 +0200,
> Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :
>
>> > I don't think the modification to the package infrastructure is ready
>> > for merging (there are many cases not handled, like when the timing
>> > data should be cleaned up, the case of overriden packages not being
>> > handled, etc.) and I am not even sure it is useful to complicate the
>> > package infrastructure with such a not-so-useful feature.
>>
>> I like the idea of having such information, so I'm in favor of these patches.
>
> Thanks :-)
>
> Though I'm still not sure of how they can be useful.
Although I may not use it every day, I can think of the following use cases:
* compare compilation speeds between different machines
* identify disk-versus-cpu bottlenecks (e.g. if the extract takes much
longer on machine A than on B, it could be the slow harddisk of A.
This can be a trigger to use another machine or faster harddisk, or an
input to the IT department)
* better visualize the impact of enabling additional packages.
* identify sudden changes in build times, e.g. after bump from one
version to another, the build time is much bigger. If you never create
the statistics, you'll never know.
>
>> (The graphs also painfully show the time lost in all ./configure
>> steps, while many of the checks are identical...)
>
> In the past, we did try to improve that situation by using the
> "configure cache" mechanism, thanks to which configure checks done by
> past configure script executions are used to speed up the execution of
> future configure scripts (since as you say, they all do mostly the same
> checks). Unfortunately, the configure scripts aren't that standardized
> and they store the result of different checks in variables of the same
> name, resulting to many strange problems. We had this feature enabled
> by default in Buildroot for a while (even in stable releases if I'm
> correct), but in the end, we dropped it because it was very complicated
> to stabilized (we already had to patch multiple configure.{in,ac}
> files).
Ok, wasn't aware of this. Thanks for the background info.
>
>> As I mentioned as comment on your patch, I think we can make this an
>> optional feature for those who want it.
>
> Yes, sure.
>
>> Is it possible to have html output as an alternative to pdf? I can
>> also imagine that some people simply want image files, like png or
>> even svg, so the graphs can easily be embedded in other web pages.
>
> Generating PNG or SVG with matplotlib is definitely possible. I'm not
> sure about HTML though, do you mean a webpage that simply includes the
> four graphs?
Some basic page with a heading for each graph, yes. It can be as fancy
as we like, but the main advantage of such a page is that you only
have to open one thing, not four individual files...
>
> 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 9/9] toolchain: speed up sysroot lib copying
From: Thomas Petazzoni @ 2011-10-10 15:19 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201110101112.18026.vapier@gentoo.org>
Le Mon, 10 Oct 2011 11:12:16 -0400,
Mike Frysinger <vapier@gentoo.org> a ?crit :
> > Just curious, is there any specific reason why you gave up working on
> > Buildroot for the Blackfin architecture?
>
> i no longer work for ADI :)
That's a good explanation.
> the people who still do are using buildroot for Blackfin, but sadly, they were
> (are?) not as active as i in pushing upstream
Ah, that's a shame, because your contributions were very interesting.
Do those people have a public tree where we can follow their
development and possibly upstream some of it ?
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 9/9] toolchain: speed up sysroot lib copying
From: Mike Frysinger @ 2011-10-10 15:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111010084424.6ef9edc0@skate>
On Monday 10 October 2011 02:44:24 Thomas Petazzoni wrote:
> Le Sun, 9 Oct 2011 22:25:40 -0400, Mike Frysinger a ?crit :
> > i'm just lurking now for buildroot as i'm not working on it anymore, but
> > this looks fine
>
> Just curious, is there any specific reason why you gave up working on
> Buildroot for the Blackfin architecture?
i no longer work for ADI :)
the people who still do are using buildroot for Blackfin, but sadly, they were
(are?) not as active as i in pushing upstream
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111010/6221bc87/attachment.asc>
^ 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