* [Buildroot] List of pending patches: what to do?
2013-07-31 17:14 [Buildroot] List of pending patches: what to do? Thomas Petazzoni
@ 2013-07-31 17:18 ` Thomas Petazzoni
2013-07-31 20:44 ` Yann E. MORIN
2013-07-31 17:51 ` Gustavo Zacarias
` (9 subsequent siblings)
10 siblings, 1 reply; 32+ messages in thread
From: Thomas Petazzoni @ 2013-07-31 17:18 UTC (permalink / raw)
To: buildroot
On Wed, 31 Jul 2013 19:14:15 +0200, Thomas Petazzoni wrote:
> http://patchwork.ozlabs.org/patch/181870 [1/9] firefox: host-python dependency needs --enable-unicodedata
> http://patchwork.ozlabs.org/patch/181871 [2/9] firefox: valgrind dependency needs --enable-tls for debug build
> http://patchwork.ozlabs.org/patch/181874 [3/9] firefox: sqlite dependency needs new compile-time options
> http://patchwork.ozlabs.org/patch/181872 [4/9] firefox: installing default extensions needs host-xmlstarlet dependency
> http://patchwork.ozlabs.org/patch/181875 [5/9] firefox: installing default extensions needs host-unzip dependency
> http://patchwork.ozlabs.org/patch/181877 [6/9] firefox: Mozilla Web Browser
> http://patchwork.ozlabs.org/patch/181876 [7/9] firefox: GNU gnash flash plugin needs agg dependency
> http://patchwork.ozlabs.org/patch/181873 [8/9] firefox: GNU gnash flash plugin needs gconf dependency
> http://patchwork.ozlabs.org/patch/181878 [9/9] firefox: GNU gnash flash, an open source Adobe Flash player & plugin
I'm proposing to drop those patches. The patches are from September
2012, and I asked Stefan Froberg in May 2013 whether he was still
interested
(http://lists.busybox.net/pipermail/buildroot/2013-May/071410.html),
and I've got a private answer that said:
"""
Well, those patches were for Firefox version 11.0 so it's quite old
already.
I have a patches for Firefox 16.0 & Firefox 18.0 done but as I
understand it Firefox is never
going to be included in buildroot so I did not post them.
And I have now also unsubscripted from mailing list so I can't post them
even if
someone would like to check them.
So, yeah. Those patches can be wiped out.
If someone from the list still want's them they can be found from
http://binarytouch.com/patches/
(I will put all the rest of my buildroot patches later there after I
have completed my current project)
"""
So unless anyone objects and steps up to refresh and resubmit those
patches, I'm proposing to mark those patches as rejected.
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 [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-07-31 17:18 ` Thomas Petazzoni
@ 2013-07-31 20:44 ` Yann E. MORIN
2013-08-01 5:39 ` Thomas Petazzoni
0 siblings, 1 reply; 32+ messages in thread
From: Yann E. MORIN @ 2013-07-31 20:44 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2013-07-31 19:18 +0200, Thomas Petazzoni spake thusly:
> On Wed, 31 Jul 2013 19:14:15 +0200, Thomas Petazzoni wrote:
> > http://patchwork.ozlabs.org/patch/181870 [1/9] firefox: host-python dependency needs --enable-unicodedata
> > http://patchwork.ozlabs.org/patch/181871 [2/9] firefox: valgrind dependency needs --enable-tls for debug build
> > http://patchwork.ozlabs.org/patch/181874 [3/9] firefox: sqlite dependency needs new compile-time options
> > http://patchwork.ozlabs.org/patch/181872 [4/9] firefox: installing default extensions needs host-xmlstarlet dependency
> > http://patchwork.ozlabs.org/patch/181875 [5/9] firefox: installing default extensions needs host-unzip dependency
> > http://patchwork.ozlabs.org/patch/181877 [6/9] firefox: Mozilla Web Browser
> > http://patchwork.ozlabs.org/patch/181876 [7/9] firefox: GNU gnash flash plugin needs agg dependency
> > http://patchwork.ozlabs.org/patch/181873 [8/9] firefox: GNU gnash flash plugin needs gconf dependency
> > http://patchwork.ozlabs.org/patch/181878 [9/9] firefox: GNU gnash flash, an open source Adobe Flash player & plugin
>
> I'm proposing to drop those patches.
Agreed.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-07-31 20:44 ` Yann E. MORIN
@ 2013-08-01 5:39 ` Thomas Petazzoni
0 siblings, 0 replies; 32+ messages in thread
From: Thomas Petazzoni @ 2013-08-01 5:39 UTC (permalink / raw)
To: buildroot
Dear Yann E. MORIN,
On Wed, 31 Jul 2013 22:44:14 +0200, Yann E. MORIN wrote:
> > > http://patchwork.ozlabs.org/patch/181870 [1/9] firefox: host-python dependency needs --enable-unicodedata
> > > http://patchwork.ozlabs.org/patch/181871 [2/9] firefox: valgrind dependency needs --enable-tls for debug build
> > > http://patchwork.ozlabs.org/patch/181874 [3/9] firefox: sqlite dependency needs new compile-time options
> > > http://patchwork.ozlabs.org/patch/181872 [4/9] firefox: installing default extensions needs host-xmlstarlet dependency
> > > http://patchwork.ozlabs.org/patch/181875 [5/9] firefox: installing default extensions needs host-unzip dependency
> > > http://patchwork.ozlabs.org/patch/181877 [6/9] firefox: Mozilla Web Browser
> > > http://patchwork.ozlabs.org/patch/181876 [7/9] firefox: GNU gnash flash plugin needs agg dependency
> > > http://patchwork.ozlabs.org/patch/181873 [8/9] firefox: GNU gnash flash plugin needs gconf dependency
> > > http://patchwork.ozlabs.org/patch/181878 [9/9] firefox: GNU gnash flash, an open source Adobe Flash player & plugin
> >
> > I'm proposing to drop those patches.
>
> Agreed.
Done, 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 [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-07-31 17:14 [Buildroot] List of pending patches: what to do? Thomas Petazzoni
2013-07-31 17:18 ` Thomas Petazzoni
@ 2013-07-31 17:51 ` Gustavo Zacarias
2013-08-01 5:50 ` Thomas Petazzoni
2013-07-31 20:45 ` Thomas De Schampheleire
` (8 subsequent siblings)
10 siblings, 1 reply; 32+ messages in thread
From: Gustavo Zacarias @ 2013-07-31 17:51 UTC (permalink / raw)
To: buildroot
On 07/31/2013 02:14 PM, Thomas Petazzoni wrote:
> http://patchwork.ozlabs.org/patch/155498 New: add lava-test package
I managed to get this working with modifications and the python fixes
(which are already in the tree).
However from what i've seen it doesn't seem useful for anything by
itself, it's a testing framework with the builtins being pretty
ubuntu-specific (and requiring a ton of other deps).
Not sure what to do about it, it's not an out-of-the-box experience, it
requires extensive tweaking to do anything useful.
> http://patchwork.ozlabs.org/patch/165542 [V2] p910nd: Add p910nd lightweight printserver
I'll rebase and give this one a try.
> http://patchwork.ozlabs.org/patch/172171 avahi: only install default.script/S05avahi-setup.sh if not present in fs skeleton
I'm generally against initscript conditionals - after all who says it'll
have the same sequence number or name in the skeleton?
Post-build script IMHO.
Otherwise a global option "don't install initscripts" might fit, however
i've been using the script just fine for ages now.
> http://patchwork.ozlabs.org/patch/178526 syslinux: fix host build with newer Linux headers
Version bump might be fitting, it's up to 6.01 now.
> http://patchwork.ozlabs.org/patch/185522 eaccelerator
> http://patchwork.ozlabs.org/patch/186837 Add config for PHP eaccelerator package. Signed-off-by: Dallas Clement <dallas.a.clement@gmail.com>
Not really an embedded-y package, eaccelerator and similar packages like
xcache are basically intermediate opcode caches for the php
interpreter/files.
Basically you set aside an X amount of RAM (in the 2-digit MiB range
usually) for that and successive hits get a good speed boost because
they don't need to be re-interpreted again and again.
This is a feature included in the PHP 5.5.x release, however i doubt
we'll be bumping soon to it, 5.4.x is a better fit for now since 5.3.x
is getting unsupported status soon.
Widely used for big PHP deployments with many page hits - so i'm hmm
about it and eventually it'll go away with PHP 5.5
And it's tied up to PHP 5.3.x so it will block a 5.4.x or 5.5.x update
unless we use the main git branch (no release yet, upstream is somewhat
dead).
> http://patchwork.ozlabs.org/patch/196141 uClibc: install libc.so even if BR2_PREFER_STATIC_LIB is enabled
We should really "mv BR2_PREFER_STATIC_LIB BR2_STATIC_BUILD" or so as
you've mentioned before - you either want or don't (want) a static build.
> http://patchwork.ozlabs.org/patch/198127 automake version update 1.12.4
for-2013.12 i'll revisit bumping automake, at the moment i'd say no, and
since there are newer versions "deferred" or "superseeded" would be
appropiate.
> http://patchwork.ozlabs.org/patch/243442 [1/6] package infra: remove CPPFLAGS from CFLAGS
> http://patchwork.ozlabs.org/patch/243445 [4/6] libcurl: bump to version 7.30.0
These depend on the generic package cleanups and some autotools package
audits (maybe fixes). I've deferred them already, they're on my TODO
list and i'll send new appropiate patches when it's done, for-2013.12.
libcurl security patches are already in the tree so there's no rush.
Regards.
^ permalink raw reply [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-07-31 17:51 ` Gustavo Zacarias
@ 2013-08-01 5:50 ` Thomas Petazzoni
0 siblings, 0 replies; 32+ messages in thread
From: Thomas Petazzoni @ 2013-08-01 5:50 UTC (permalink / raw)
To: buildroot
Dear Gustavo Zacarias,
On Wed, 31 Jul 2013 14:51:57 -0300, Gustavo Zacarias wrote:
> On 07/31/2013 02:14 PM, Thomas Petazzoni wrote:
>
> > http://patchwork.ozlabs.org/patch/155498 New: add lava-test package
>
> I managed to get this working with modifications and the python fixes
> (which are already in the tree).
> However from what i've seen it doesn't seem useful for anything by
> itself, it's a testing framework with the builtins being pretty
> ubuntu-specific (and requiring a ton of other deps).
> Not sure what to do about it, it's not an out-of-the-box experience, it
> requires extensive tweaking to do anything useful.
So I'm proposing to drop this patch. There isn't much interest from the
current Buildroot contributors, and the original submitter hasn't
pushed the patch forward that much.
> > http://patchwork.ozlabs.org/patch/165542 [V2] p910nd: Add p910nd lightweight printserver
>
> I'll rebase and give this one a try.
Good, patch delegated to you.
> > http://patchwork.ozlabs.org/patch/172171 avahi: only install default.script/S05avahi-setup.sh if not present in fs skeleton
>
> I'm generally against initscript conditionals - after all who says it'll
> have the same sequence number or name in the skeleton?
> Post-build script IMHO.
> Otherwise a global option "don't install initscripts" might fit, however
> i've been using the script just fine for ages now.
In fact, I realize the patch here is not a patch against Buildroot,
it's just a diff I had done between two udhcpc scripts (the one
installed by Avahi and the one installed by Busybox), and recently,
through commit 0c229f70ea270069e981bfb59e3aea80b21bbcfb, Peter merged
the two. So I'll mark this patch as rejected.
> > http://patchwork.ozlabs.org/patch/178526 syslinux: fix host build with newer Linux headers
>
> Version bump might be fitting, it's up to 6.01 now.
Indeed. So let's keep this patch around as a reminder to do something
about syslinux bump.
> > http://patchwork.ozlabs.org/patch/185522 eaccelerator
> > http://patchwork.ozlabs.org/patch/186837 Add config for PHP eaccelerator package. Signed-off-by: Dallas Clement <dallas.a.clement@gmail.com>
>
> Not really an embedded-y package, eaccelerator and similar packages like
> xcache are basically intermediate opcode caches for the php
> interpreter/files.
> Basically you set aside an X amount of RAM (in the 2-digit MiB range
> usually) for that and successive hits get a good speed boost because
> they don't need to be re-interpreted again and again.
> This is a feature included in the PHP 5.5.x release, however i doubt
> we'll be bumping soon to it, 5.4.x is a better fit for now since 5.3.x
> is getting unsupported status soon.
> Widely used for big PHP deployments with many page hits - so i'm hmm
> about it and eventually it'll go away with PHP 5.5
> And it's tied up to PHP 5.3.x so it will block a 5.4.x or 5.5.x update
> unless we use the main git branch (no release yet, upstream is somewhat
> dead).
I marked the first as Superseded. For the second one, I replied to the
patch submitter to see if he's still interested.
> > http://patchwork.ozlabs.org/patch/196141 uClibc: install libc.so even if BR2_PREFER_STATIC_LIB is enabled
>
> We should really "mv BR2_PREFER_STATIC_LIB BR2_STATIC_BUILD" or so as
> you've mentioned before - you either want or don't (want) a static build.
Agreed. Keeping this around for now until the static lib mess gets
fixed. I might be tackling this for 2013.11.
> > http://patchwork.ozlabs.org/patch/198127 automake version update 1.12.4
>
> for-2013.12 i'll revisit bumping automake, at the moment i'd say no, and
> since there are newer versions "deferred" or "superseeded" would be
> appropiate.
Shouldn't we keep it around as a reminder to do something about
automake?
> > http://patchwork.ozlabs.org/patch/243442 [1/6] package infra: remove CPPFLAGS from CFLAGS
> > http://patchwork.ozlabs.org/patch/243445 [4/6] libcurl: bump to version 7.30.0
>
> These depend on the generic package cleanups and some autotools package
> audits (maybe fixes). I've deferred them already, they're on my TODO
> list and i'll send new appropiate patches when it's done, for-2013.12.
> libcurl security patches are already in the tree so there's no rush.
Ok, 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 [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-07-31 17:14 [Buildroot] List of pending patches: what to do? Thomas Petazzoni
2013-07-31 17:18 ` Thomas Petazzoni
2013-07-31 17:51 ` Gustavo Zacarias
@ 2013-07-31 20:45 ` Thomas De Schampheleire
2013-07-31 20:57 ` Yann E. MORIN
2013-08-01 5:59 ` Thomas Petazzoni
2013-07-31 20:55 ` Yann E. MORIN
` (7 subsequent siblings)
10 siblings, 2 replies; 32+ messages in thread
From: Thomas De Schampheleire @ 2013-07-31 20:45 UTC (permalink / raw)
To: buildroot
Hi,
On Wed, Jul 31, 2013 at 7:14 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
Very quick initial run-through:
> http://patchwork.ozlabs.org/patch/188525 Question about 64Bit kernel and 32Bit applications
Can be closed, that problem was fixed differently.
> http://patchwork.ozlabs.org/patch/201313 Passing arguments to the linker when external toolchain is used.
Can also be closed for the same reason.
> http://patchwork.ozlabs.org/patch/207717 dtb: provide option to install dtb to boot directory
At first sight, this feature is already present but with a slightly
different implementation. Could you double-check?
> http://patchwork.ozlabs.org/patch/231856 Install DTB as part of images install command
Seems to have been acked by several people, can be applied as-is?
> http://patchwork.ozlabs.org/patch/241250 toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS
Needs to be updated to latest buildroot, but has been acked by Arnout
before, after two other iterations.
> http://patchwork.ozlabs.org/patch/249635 UCLIBC_EXTRA_CFLAGS in uClibc overridden while using buildroot
> http://patchwork.ozlabs.org/patch/249855 UCLIBC_EXTRA_CFLAGS in uClibc overridden while using buildroot
Former is the old one, can be closed.
> http://patchwork.ozlabs.org/patch/256744 tar: avoid ccache chicken and egg problem when bootstrapping tar
I'm going to test this.
> http://patchwork.ozlabs.org/patch/260246 xzcat: treat as host prerequisite and build if needed
This is one of mine, feedback would be welcome. I tested it and it works :)
Best regards,
Thomas
^ permalink raw reply [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-07-31 20:45 ` Thomas De Schampheleire
@ 2013-07-31 20:57 ` Yann E. MORIN
2013-08-01 5:59 ` Thomas Petazzoni
1 sibling, 0 replies; 32+ messages in thread
From: Yann E. MORIN @ 2013-07-31 20:57 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2013-07-31 22:45 +0200, Thomas De Schampheleire spake thusly:
> > http://patchwork.ozlabs.org/patch/249635 UCLIBC_EXTRA_CFLAGS in uClibc overridden while using buildroot
> > http://patchwork.ozlabs.org/patch/249855 UCLIBC_EXTRA_CFLAGS in uClibc overridden while using buildroot
>
> Former is the old one, can be closed.
Marked as "superseded", thanks.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-07-31 20:45 ` Thomas De Schampheleire
2013-07-31 20:57 ` Yann E. MORIN
@ 2013-08-01 5:59 ` Thomas Petazzoni
2013-08-01 20:24 ` Yann E. MORIN
1 sibling, 1 reply; 32+ messages in thread
From: Thomas Petazzoni @ 2013-08-01 5:59 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Wed, 31 Jul 2013 22:45:28 +0200, Thomas De Schampheleire wrote:
> > http://patchwork.ozlabs.org/patch/188525 Question about 64Bit kernel and 32Bit applications
>
> Can be closed, that problem was fixed differently.
Done.
> > http://patchwork.ozlabs.org/patch/201313 Passing arguments to the linker when external toolchain is used.
>
> Can also be closed for the same reason.
Done.
> > http://patchwork.ozlabs.org/patch/207717 dtb: provide option to install dtb to boot directory
>
> At first sight, this feature is already present but with a slightly
> different implementation. Could you double-check?
Yes, I need to have a look today at several DTB/uImage/initramfs
patches against linux.mk, I'll try to have a look at that one.
> > http://patchwork.ozlabs.org/patch/231856 Install DTB as part of images install command
>
> Seems to have been acked by several people, can be applied as-is?
Agreed.
> > http://patchwork.ozlabs.org/patch/241250 toolchain/gcc: Introduce BR2_ARCH_HAS_GCC_x_y_PLUS
>
> Needs to be updated to latest buildroot, but has been acked by Arnout
> before, after two other iterations.
I'd be inclined to post-pone that for 2013.11, but I can merge it as
soon as -next opens.
> > http://patchwork.ozlabs.org/patch/249635 UCLIBC_EXTRA_CFLAGS in uClibc overridden while using buildroot
> > http://patchwork.ozlabs.org/patch/249855 UCLIBC_EXTRA_CFLAGS in uClibc overridden while using buildroot
>
> Former is the old one, can be closed.
Apparently someone marked 249635 as superseded in the mean time.
> > http://patchwork.ozlabs.org/patch/256744 tar: avoid ccache chicken and egg problem when bootstrapping tar
>
> I'm going to test this.
Ok.
> > http://patchwork.ozlabs.org/patch/260246 xzcat: treat as host prerequisite and build if needed
>
> This is one of mine, feedback would be welcome. I tested it and it works :)
The only part I'm not entirely happy with is:
- DL_TOOLS="$(sort $(DL_TOOLS_DEPENDENCIES))" \
+ DL_TOOLS="$(sort $(filter-out $(XZCAT),$(DL_TOOLS_DEPENDENCIES)))" \
This looks like very special-case filtering. It sounds odd to add xzcat
to DL_TOOLS_DEPENDENCIES to later remove it when DL_TOOLS_DEPENDENCIES
is used. I think I'd prefer something along the lines of (but it'd be
great if a temporary variable could be used for the $(firstword ...)
thing) :
diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index b8eaa98..435a1c6 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -539,7 +539,11 @@ else ifeq ($$($(2)_SITE_METHOD),hg)
DL_TOOLS_DEPENDENCIES += hg
endif # SITE_METHOD
+# Do not add xzcat to the list of required dependencies, as it gets
+# built automatically if it isn't found.
+ifneq ($(firstword $(INFLATE$(suffix $($(2)_SOURCE)))),$(XZCAT))
DL_TOOLS_DEPENDENCIES += $(firstword $(INFLATE$(suffix $($(2)_SOURCE))))
+endif
endif # $(2)_KCONFIG_VAR
endef # inner-generic-package
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-08-01 5:59 ` Thomas Petazzoni
@ 2013-08-01 20:24 ` Yann E. MORIN
0 siblings, 0 replies; 32+ messages in thread
From: Yann E. MORIN @ 2013-08-01 20:24 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2013-08-01 07:59 +0200, Thomas Petazzoni spake thusly:
> On Wed, 31 Jul 2013 22:45:28 +0200, Thomas De Schampheleire wrote:
> > > http://patchwork.ozlabs.org/patch/249635 UCLIBC_EXTRA_CFLAGS in uClibc overridden while using buildroot
> > > http://patchwork.ozlabs.org/patch/249855 UCLIBC_EXTRA_CFLAGS in uClibc overridden while using buildroot
> >
> > Former is the old one, can be closed.
>
> Apparently someone marked 249635 as superseded in the mean time.
That would be me, but as I had email issues since around midnight (GMT+2)
yesterday, up until late in the afternoon today [*], so my mail probably
stayed in limbo and was not delivered before you looked at the patchwork.
That about 5 other millions french internet users had the same issue as
me is of little comfort. :-(
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-07-31 17:14 [Buildroot] List of pending patches: what to do? Thomas Petazzoni
` (2 preceding siblings ...)
2013-07-31 20:45 ` Thomas De Schampheleire
@ 2013-07-31 20:55 ` Yann E. MORIN
2013-08-01 6:04 ` Thomas Petazzoni
2013-07-31 22:13 ` Samuel Martin
` (6 subsequent siblings)
10 siblings, 1 reply; 32+ messages in thread
From: Yann E. MORIN @ 2013-07-31 20:55 UTC (permalink / raw)
To: buildroot
Thomas, All,
On 2013-07-31 19:14 +0200, Thomas Petazzoni spake thusly:
> We currently have 228 pending patches in our patchwork
[--SNIP--]
> http://patchwork.ozlabs.org/patch/247051 Makefile: add variable print capabilities
That one I'm sponsoring. It applies with a fuzz of 1, so can get in.
It's usefull to dump the internal variable of Buildroot to check nothing
has gone amiss.
I'm having a look at others.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-07-31 20:55 ` Yann E. MORIN
@ 2013-08-01 6:04 ` Thomas Petazzoni
0 siblings, 0 replies; 32+ messages in thread
From: Thomas Petazzoni @ 2013-08-01 6:04 UTC (permalink / raw)
To: buildroot
Dear Yann E. MORIN,
On Wed, 31 Jul 2013 22:55:04 +0200, Yann E. MORIN wrote:
> Thomas, All,
>
> On 2013-07-31 19:14 +0200, Thomas Petazzoni spake thusly:
> > We currently have 228 pending patches in our patchwork
> [--SNIP--]
> > http://patchwork.ozlabs.org/patch/247051 Makefile: add variable print capabilities
>
> That one I'm sponsoring. It applies with a fuzz of 1, so can get in.
Ok, applied, 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 [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-07-31 17:14 [Buildroot] List of pending patches: what to do? Thomas Petazzoni
` (3 preceding siblings ...)
2013-07-31 20:55 ` Yann E. MORIN
@ 2013-07-31 22:13 ` Samuel Martin
2013-07-31 22:20 ` Yann E. MORIN
2013-08-01 16:23 ` Thomas Petazzoni
2013-08-01 2:52 ` Danomi Manchego
` (5 subsequent siblings)
10 siblings, 2 replies; 32+ messages in thread
From: Samuel Martin @ 2013-07-31 22:13 UTC (permalink / raw)
To: buildroot
Hi all,
2013/7/31 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> http://patchwork.ozlabs.org/patch/243426 Fix bug with dependencies of *-rebuild and *-reconfigure
> http://patchwork.ozlabs.org/patch/172278 pkg-infra: limit -reconfigure and -rebuild actions
Both treat the same thing!
A "political decision" has to be made on this since it slightly
changes the way some BR commands work.
> http://patchwork.ozlabs.org/patch/172506 [01/11] libgpg-error: add optional nls support
To be dropped, nobody needs it.
> http://patchwork.ozlabs.org/patch/189336 libglib2: Fix midori save file dialog not being rendered
AFAICS, this one is no longer needed.
It fix a glib-2.32 issue, and now we provide the 2.36 version.
> http://patchwork.ozlabs.org/patch/200889 [04/33] igh-ethercat: disable drivers build with kernel 3.6
> http://patchwork.ozlabs.org/patch/200896 [05/33] imagemagick: explicitly disable c++ support if no c++ compiler available
> http://patchwork.ozlabs.org/patch/200909 [20/33] pkg-download.mk: add tarball check in the wget method
> http://patchwork.ozlabs.org/patch/204804 flite: new package
> http://patchwork.ozlabs.org/patch/204806 libcanfestival: new package
Still in my stack.
Postponed to the next release.
> http://patchwork.ozlabs.org/patch/208801 [3/8] package/Makefile.in: update/fix HOST_PATH variable
> http://patchwork.ozlabs.org/patch/208802 [4/8] package/pkg-cmake.mk: make sure $(HOST_PATH) is in the PATH at configure time
Still in my stack.
Part of some infra cleanup.
Postponed to the next release.
> http://patchwork.ozlabs.org/patch/208803 [5/8] dependencies: build a host python2 if no suitable one can be found
> http://patchwork.ozlabs.org/patch/208804 [6/8] scons: add host-python2-if-needed dependency
> http://patchwork.ozlabs.org/patch/208805 [7/8] scons: ensure $(HOST_DIR)/usr/bin is in the PATH when invoking $(SCONS)
> http://patchwork.ozlabs.org/patch/208806 [8/8] manual: add host python2 dependency section
Still in my stack.
Part of some infra cleanup.
If nobody but me cares about this, then I don't mind dropping them;
I'll keep them locally.
> http://patchwork.ozlabs.org/patch/214943 [1/1] Documentation update : add tips to build manual, add information about buildroot toolchain not being relocable and put some hints to use it, move the Beyond Buildroot section before FAQs and add content
> http://patchwork.ozlabs.org/patch/216485 Docu: Add LIBFOO_EXTRACT_CMDS
> http://patchwork.ozlabs.org/patch/232024 [1/1] manual: add patch revision and versioning section
Doc/manual: need review/respin/rebase imho. Can wait for the next release cycle.
> http://patchwork.ozlabs.org/patch/230289 [v2] Enable ccache for cmake packages
> http://patchwork.ozlabs.org/patch/243442 [1/6] package infra: remove CPPFLAGS from CFLAGS
Part of some cleanup I have in my stack and I'd like to do for the next release.
> http://patchwork.ozlabs.org/patch/244409 [1/1] libtirpc: requires toolchain with threads support
Fixes autobuilders, and is the v2 of a patch, including comments from
the 1st submission.
> http://patchwork.ozlabs.org/patch/182233 Depend autotools targets on host-ccache when BR2_CCACHE is enabled.
> http://patchwork.ozlabs.org/patch/256744 tar: avoid ccache chicken and egg problem when bootstrapping tar
> http://patchwork.ozlabs.org/patch/257372 [1/3] infra: make possible to run 'make *-menuconfig' from a clean output dir
ccache chicken-egg issue that need to be carefully handled.
> http://patchwork.ozlabs.org/patch/257374 [2/3] crosstool-ng: remove unneed explicit ccache dependency
> http://patchwork.ozlabs.org/patch/257375 [3/3] sstrip: remove unneed explicit ccache dependency
Few more ccache cleanups after the previous issue is fixed.
> http://patchwork.ozlabs.org/patch/257376 [1/3] qt{4, 5}: add an explicit choice to express Buildroot does not support their coexistence
> http://patchwork.ozlabs.org/patch/257377 [2/3] manual: add faq entry explaining why Buildroot does not support Qt{4, 5} coexistence
> http://patchwork.ozlabs.org/patch/257378 [3/3] opencv: bump version to 2.4.6
Still in my stack.
I will rework them during the next release cycle.
Regards,
--
Samuel
^ permalink raw reply [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-07-31 22:13 ` Samuel Martin
@ 2013-07-31 22:20 ` Yann E. MORIN
2013-08-01 16:23 ` Thomas Petazzoni
1 sibling, 0 replies; 32+ messages in thread
From: Yann E. MORIN @ 2013-07-31 22:20 UTC (permalink / raw)
To: buildroot
Samuel, All,
On 2013-08-01 00:13 +0200, Samuel Martin spake thusly:
> > http://patchwork.ozlabs.org/patch/189336 libglib2: Fix midori save file dialog not being rendered
> AFAICS, this one is no longer needed.
> It fix a glib-2.32 issue, and now we provide the 2.36 version.
Marked as superseded, then. Thanks.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-07-31 22:13 ` Samuel Martin
2013-07-31 22:20 ` Yann E. MORIN
@ 2013-08-01 16:23 ` Thomas Petazzoni
2013-08-01 21:30 ` Samuel Martin
1 sibling, 1 reply; 32+ messages in thread
From: Thomas Petazzoni @ 2013-08-01 16:23 UTC (permalink / raw)
To: buildroot
Dear Samuel Martin,
On Thu, 1 Aug 2013 00:13:35 +0200, Samuel Martin wrote:
> 2013/7/31 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
>
> > http://patchwork.ozlabs.org/patch/243426 Fix bug with dependencies of *-rebuild and *-reconfigure
> > http://patchwork.ozlabs.org/patch/172278 pkg-infra: limit -reconfigure and -rebuild actions
> Both treat the same thing!
> A "political decision" has to be made on this since it slightly
> changes the way some BR commands work.
Can we have a decision on those ones?
On my side, I kind of like the fact that 'make blabla-rebuild' both
rebuilds the blabla package and regenerates the root filesystem. It
avoids the need for 'make blabla-rebuild && make'. However, it's true
that it's inconsistent with 'make blabla-dirclean', which just removes
the build directory, and therefore requires a 'make blabla-dirclean &&
make' if you want to completely rebuild a package from scratch.
> > http://patchwork.ozlabs.org/patch/172506 [01/11] libgpg-error: add optional nls support
> To be dropped, nobody needs it.
Done.
> > http://patchwork.ozlabs.org/patch/200889 [04/33] igh-ethercat: disable drivers build with kernel 3.6
> > http://patchwork.ozlabs.org/patch/200896 [05/33] imagemagick: explicitly disable c++ support if no c++ compiler available
> > http://patchwork.ozlabs.org/patch/200909 [20/33] pkg-download.mk: add tarball check in the wget method
> > http://patchwork.ozlabs.org/patch/204804 flite: new package
> > http://patchwork.ozlabs.org/patch/204806 libcanfestival: new package
> Still in my stack.
> Postponed to the next release.
Does this mean I can mark them as 'Deferred' in patchwork, trusting you
to resubmit them later? Or should I keep them around in patchwork just
to remind us (you and the community) that they need to be finalized and
merged?
> > http://patchwork.ozlabs.org/patch/208801 [3/8] package/Makefile.in: update/fix HOST_PATH variable
> > http://patchwork.ozlabs.org/patch/208802 [4/8] package/pkg-cmake.mk: make sure $(HOST_PATH) is in the PATH at configure time
> Still in my stack.
> Part of some infra cleanup.
> Postponed to the next release.
Same question as above.
>
> > http://patchwork.ozlabs.org/patch/208803 [5/8] dependencies: build a host python2 if no suitable one can be found
> > http://patchwork.ozlabs.org/patch/208804 [6/8] scons: add host-python2-if-needed dependency
> > http://patchwork.ozlabs.org/patch/208805 [7/8] scons: ensure $(HOST_DIR)/usr/bin is in the PATH when invoking $(SCONS)
> > http://patchwork.ozlabs.org/patch/208806 [8/8] manual: add host python2 dependency section
> Still in my stack.
> Part of some infra cleanup.
> If nobody but me cares about this, then I don't mind dropping them;
> I'll keep them locally.
Same question as above.
> > http://patchwork.ozlabs.org/patch/214943 [1/1] Documentation update : add tips to build manual, add information about buildroot toolchain not being relocable and put some hints to use it, move the Beyond Buildroot section before FAQs and add content
> > http://patchwork.ozlabs.org/patch/216485 Docu: Add LIBFOO_EXTRACT_CMDS
> > http://patchwork.ozlabs.org/patch/232024 [1/1] manual: add patch revision and versioning section
> Doc/manual: need review/respin/rebase imho. Can wait for the next release cycle.
Documentation stuff can be merged after -rc1, so it'd be great to
clean that up now and get it merged during the -rc cycle.
> > http://patchwork.ozlabs.org/patch/230289 [v2] Enable ccache for cmake packages
> > http://patchwork.ozlabs.org/patch/243442 [1/6] package infra: remove CPPFLAGS from CFLAGS
> Part of some cleanup I have in my stack and I'd like to do for the next release.
Same question as above (should I mark as Deferred or keep in patchwork
as a reminder).
> > http://patchwork.ozlabs.org/patch/244409 [1/1] libtirpc: requires toolchain with threads support
> Fixes autobuilders, and is the v2 of a patch, including comments from
> the 1st submission.
Ah, yes, I didn't like the fact of adding a thread dependency to
libtirpc, but I think I should like it. This is really a bug fix, so
can always be merged after -rc1 is released.
> > http://patchwork.ozlabs.org/patch/182233 Depend autotools targets on host-ccache when BR2_CCACHE is enabled.
> > http://patchwork.ozlabs.org/patch/256744 tar: avoid ccache chicken and egg problem when bootstrapping tar
> > http://patchwork.ozlabs.org/patch/257372 [1/3] infra: make possible to run 'make *-menuconfig' from a clean output dir
> ccache chicken-egg issue that need to be carefully handled.
>
> > http://patchwork.ozlabs.org/patch/257374 [2/3] crosstool-ng: remove unneed explicit ccache dependency
> > http://patchwork.ozlabs.org/patch/257375 [3/3] sstrip: remove unneed explicit ccache dependency
> Few more ccache cleanups after the previous issue is fixed.
Discussion started with Thomas De Schampheleire today about this.
> > http://patchwork.ozlabs.org/patch/257376 [1/3] qt{4, 5}: add an explicit choice to express Buildroot does not support their coexistence
> > http://patchwork.ozlabs.org/patch/257377 [2/3] manual: add faq entry explaining why Buildroot does not support Qt{4, 5} coexistence
> > http://patchwork.ozlabs.org/patch/257378 [3/3] opencv: bump version to 2.4.6
> Still in my stack.
> I will rework them during the next release cycle.
Same question as above. I'm not sure a FAQ entry is a good choice,
maybe a
comment "qt5 is not available when qt4 is selected"
depends on BR2_PACKAGE_QT
comment "qt4 is not available when qt5 is selected"
depend son BR2_PACKAGE_QT5
is probably a better idea.
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 [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-08-01 16:23 ` Thomas Petazzoni
@ 2013-08-01 21:30 ` Samuel Martin
2013-08-02 8:33 ` Thomas De Schampheleire
0 siblings, 1 reply; 32+ messages in thread
From: Samuel Martin @ 2013-08-01 21:30 UTC (permalink / raw)
To: buildroot
Thomas, all,
2013/8/1 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Dear Samuel Martin,
>
> On Thu, 1 Aug 2013 00:13:35 +0200, Samuel Martin wrote:
>
>> 2013/7/31 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
>>
>> > http://patchwork.ozlabs.org/patch/243426 Fix bug with dependencies of *-rebuild and *-reconfigure
>> > http://patchwork.ozlabs.org/patch/172278 pkg-infra: limit -reconfigure and -rebuild actions
>> Both treat the same thing!
>> A "political decision" has to be made on this since it slightly
>> changes the way some BR commands work.
>
> Can we have a decision on those ones?
>
> On my side, I kind of like the fact that 'make blabla-rebuild' both
> rebuilds the blabla package and regenerates the root filesystem. It
> avoids the need for 'make blabla-rebuild && make'. However, it's true
> that it's inconsistent with 'make blabla-dirclean', which just removes
> the build directory, and therefore requires a 'make blabla-dirclean &&
> make' if you want to completely rebuild a package from scratch.
IIRC, we talked about this during some BR dev days or patchwork-day
session, and in the end we kept statu quo.
I'd rather be in favor of these patches, although I barely use the
*-re{configure,build} targets;
anyway it's just one opinion among others.
>
>> > http://patchwork.ozlabs.org/patch/172506 [01/11] libgpg-error: add optional nls support
>> To be dropped, nobody needs it.
>
> Done.
>
>
>> > http://patchwork.ozlabs.org/patch/200889 [04/33] igh-ethercat: disable drivers build with kernel 3.6
>> > http://patchwork.ozlabs.org/patch/200896 [05/33] imagemagick: explicitly disable c++ support if no c++ compiler available
>> > http://patchwork.ozlabs.org/patch/200909 [20/33] pkg-download.mk: add tarball check in the wget method
>> > http://patchwork.ozlabs.org/patch/204804 flite: new package
>> > http://patchwork.ozlabs.org/patch/204806 libcanfestival: new package
>> Still in my stack.
>> Postponed to the next release.
>
> Does this mean I can mark them as 'Deferred' in patchwork, trusting you
> to resubmit them later? Or should I keep them around in patchwork just
> to remind us (you and the community) that they need to be finalized and
> merged?
Yes, I've just marked them as deferred.
>
>> > http://patchwork.ozlabs.org/patch/208801 [3/8] package/Makefile.in: update/fix HOST_PATH variable
>> > http://patchwork.ozlabs.org/patch/208802 [4/8] package/pkg-cmake.mk: make sure $(HOST_PATH) is in the PATH at configure time
>> Still in my stack.
>> Part of some infra cleanup.
>> Postponed to the next release.
>
> Same question as above.
done
>
>>
>> > http://patchwork.ozlabs.org/patch/208803 [5/8] dependencies: build a host python2 if no suitable one can be found
>> > http://patchwork.ozlabs.org/patch/208804 [6/8] scons: add host-python2-if-needed dependency
>> > http://patchwork.ozlabs.org/patch/208805 [7/8] scons: ensure $(HOST_DIR)/usr/bin is in the PATH when invoking $(SCONS)
>> > http://patchwork.ozlabs.org/patch/208806 [8/8] manual: add host python2 dependency section
>> Still in my stack.
>> Part of some infra cleanup.
>> If nobody but me cares about this, then I don't mind dropping them;
>> I'll keep them locally.
>
> Same question as above.
done
>
>> > http://patchwork.ozlabs.org/patch/214943 [1/1] Documentation update : add tips to build manual, add information about buildroot toolchain not being relocable and put some hints to use it, move the Beyond Buildroot section before FAQs and add content
>> > http://patchwork.ozlabs.org/patch/216485 Docu: Add LIBFOO_EXTRACT_CMDS
>> > http://patchwork.ozlabs.org/patch/232024 [1/1] manual: add patch revision and versioning section
>> Doc/manual: need review/respin/rebase imho. Can wait for the next release cycle.
>
> Documentation stuff can be merged after -rc1, so it'd be great to
> clean that up now and get it merged during the -rc cycle.
Yes, I'll try to look at these patches shortly.
>
>> > http://patchwork.ozlabs.org/patch/230289 [v2] Enable ccache for cmake packages
>> > http://patchwork.ozlabs.org/patch/243442 [1/6] package infra: remove CPPFLAGS from CFLAGS
>> Part of some cleanup I have in my stack and I'd like to do for the next release.
>
> Same question as above (should I mark as Deferred or keep in patchwork
> as a reminder).
Yes, please. Thomas, could you do it, I cannot since they are not mine.
>
>> > http://patchwork.ozlabs.org/patch/244409 [1/1] libtirpc: requires toolchain with threads support
>> Fixes autobuilders, and is the v2 of a patch, including comments from
>> the 1st submission.
>
> Ah, yes, I didn't like the fact of adding a thread dependency to
> libtirpc, but I think I should like it. This is really a bug fix, so
> can always be merged after -rc1 is released.
>
>> > http://patchwork.ozlabs.org/patch/182233 Depend autotools targets on host-ccache when BR2_CCACHE is enabled.
>> > http://patchwork.ozlabs.org/patch/256744 tar: avoid ccache chicken and egg problem when bootstrapping tar
>> > http://patchwork.ozlabs.org/patch/257372 [1/3] infra: make possible to run 'make *-menuconfig' from a clean output dir
>> ccache chicken-egg issue that need to be carefully handled.
>>
>> > http://patchwork.ozlabs.org/patch/257374 [2/3] crosstool-ng: remove unneed explicit ccache dependency
>> > http://patchwork.ozlabs.org/patch/257375 [3/3] sstrip: remove unneed explicit ccache dependency
>> Few more ccache cleanups after the previous issue is fixed.
>
> Discussion started with Thomas De Schampheleire today about this.
Indeed, I follow the discussion but cannot be more involved right now.
>
>> > http://patchwork.ozlabs.org/patch/257376 [1/3] qt{4, 5}: add an explicit choice to express Buildroot does not support their coexistence
>> > http://patchwork.ozlabs.org/patch/257377 [2/3] manual: add faq entry explaining why Buildroot does not support Qt{4, 5} coexistence
>> > http://patchwork.ozlabs.org/patch/257378 [3/3] opencv: bump version to 2.4.6
>> Still in my stack.
>> I will rework them during the next release cycle.
>
> Same question as above.
done
> I'm not sure a FAQ entry is a good choice,
> maybe a
>
> comment "qt5 is not available when qt4 is selected"
> depends on BR2_PACKAGE_QT
>
> comment "qt4 is not available when qt5 is selected"
> depend son BR2_PACKAGE_QT5
>
> is probably a better idea.
Fair enough, I'll integrate this change when I'll respin this series.
Thx,
Regards,
--
Samuel
^ permalink raw reply [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-08-01 21:30 ` Samuel Martin
@ 2013-08-02 8:33 ` Thomas De Schampheleire
2013-08-02 8:50 ` Thomas Petazzoni
2013-08-12 21:01 ` Arnout Vandecappelle
0 siblings, 2 replies; 32+ messages in thread
From: Thomas De Schampheleire @ 2013-08-02 8:33 UTC (permalink / raw)
To: buildroot
On Thu, Aug 1, 2013 at 11:30 PM, Samuel Martin <s.martin49@gmail.com> wrote:
> Thomas, all,
>
> 2013/8/1 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
>> Dear Samuel Martin,
>>
>> On Thu, 1 Aug 2013 00:13:35 +0200, Samuel Martin wrote:
>>
>>> 2013/7/31 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
>>>
>>> > http://patchwork.ozlabs.org/patch/243426 Fix bug with dependencies of *-rebuild and *-reconfigure
>>> > http://patchwork.ozlabs.org/patch/172278 pkg-infra: limit -reconfigure and -rebuild actions
>>> Both treat the same thing!
>>> A "political decision" has to be made on this since it slightly
>>> changes the way some BR commands work.
>>
>> Can we have a decision on those ones?
>>
>> On my side, I kind of like the fact that 'make blabla-rebuild' both
>> rebuilds the blabla package and regenerates the root filesystem. It
>> avoids the need for 'make blabla-rebuild && make'. However, it's true
>> that it's inconsistent with 'make blabla-dirclean', which just removes
>> the build directory, and therefore requires a 'make blabla-dirclean &&
>> make' if you want to completely rebuild a package from scratch.
>
> IIRC, we talked about this during some BR dev days or patchwork-day
> session, and in the end we kept statu quo.
>
> I'd rather be in favor of these patches, although I barely use the
> *-re{configure,build} targets;
> anyway it's just one opinion among others.
>
I am currently used to -reconfigure and -rebuild to rebuild also the
rootfs, but I also agree it's inconsistent with the other targets. If
we want to be strict, then foo-reconfigure can only configure, not
build. And foo-rebuild can only build.
Hence, to get the original behavior of:
foo-reconfigure --> foo-reconfigure all
foo-rebuild --> foo-rebuild all
Is that understanding correct?
As long as we can document this properly, also in the ChangeLog, then
I'm fine with this semantic change. Adding 'all' isn't the end of the
world.
Best regards,
Thomas
^ permalink raw reply [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-08-02 8:33 ` Thomas De Schampheleire
@ 2013-08-02 8:50 ` Thomas Petazzoni
2013-08-02 9:09 ` Thomas De Schampheleire
2013-08-12 21:01 ` Arnout Vandecappelle
1 sibling, 1 reply; 32+ messages in thread
From: Thomas Petazzoni @ 2013-08-02 8:50 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Fri, 2 Aug 2013 10:33:18 +0200, Thomas De Schampheleire wrote:
> I am currently used to -reconfigure and -rebuild to rebuild also the
> rootfs, but I also agree it's inconsistent with the other targets. If
> we want to be strict, then foo-reconfigure can only configure, not
> build. And foo-rebuild can only build.
Yerk, that's a bit ugly. foo-reconfigure removes the configure, build
stamp files as well as the host, staging, images and target install
stamp files. foo-rebuild does the same, except for the configure stamp
file.
So, I would find it strange if foo-reconfigure only did the configure
again and not the entire package build process. Same for foo-rebuild.
Remember, the use case for those is someone who is actively working on
the source code of a package (mainly when using the OVERRIDE_SRCDIR
thing or the local site method) and wants to be able to restart the
build of the package, just as if he was running 'make && make install'
in his package source code.
So the intention is really to have 'make foo-rebuild' do that 'make &&
make install' for the user, for the package <foo>.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-08-02 8:50 ` Thomas Petazzoni
@ 2013-08-02 9:09 ` Thomas De Schampheleire
2013-08-02 9:10 ` Thomas Petazzoni
0 siblings, 1 reply; 32+ messages in thread
From: Thomas De Schampheleire @ 2013-08-02 9:09 UTC (permalink / raw)
To: buildroot
On Fri, Aug 2, 2013 at 10:50 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Fri, 2 Aug 2013 10:33:18 +0200, Thomas De Schampheleire wrote:
>
>> I am currently used to -reconfigure and -rebuild to rebuild also the
>> rootfs, but I also agree it's inconsistent with the other targets. If
>> we want to be strict, then foo-reconfigure can only configure, not
>> build. And foo-rebuild can only build.
>
> Yerk, that's a bit ugly. foo-reconfigure removes the configure, build
> stamp files as well as the host, staging, images and target install
> stamp files. foo-rebuild does the same, except for the configure stamp
> file.
>
> So, I would find it strange if foo-reconfigure only did the configure
> again and not the entire package build process. Same for foo-rebuild.
>
> Remember, the use case for those is someone who is actively working on
> the source code of a package (mainly when using the OVERRIDE_SRCDIR
> thing or the local site method) and wants to be able to restart the
> build of the package, just as if he was running 'make && make install'
> in his package source code.
>
> So the intention is really to have 'make foo-rebuild' do that 'make &&
> make install' for the user, for the package <foo>.
As said, I don't have a problem with the existing
reconfigure-does-it-all approach.
I may have misunderstood the objections of others: there is no
objection against reconfigure doing also rebuild, only that
reconfigure and rebuild also make the rootfs?
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-08-02 9:09 ` Thomas De Schampheleire
@ 2013-08-02 9:10 ` Thomas Petazzoni
2013-08-02 9:27 ` Thomas De Schampheleire
0 siblings, 1 reply; 32+ messages in thread
From: Thomas Petazzoni @ 2013-08-02 9:10 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Fri, 2 Aug 2013 11:09:11 +0200, Thomas De Schampheleire wrote:
> > So the intention is really to have 'make foo-rebuild' do that 'make &&
> > make install' for the user, for the package <foo>.
>
> As said, I don't have a problem with the existing
> reconfigure-does-it-all approach.
> I may have misunderstood the objections of others: there is no
> objection against reconfigure doing also rebuild, only that
> reconfigure and rebuild also make the rootfs?
That's my understanding of what the objections are, yes.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-08-02 9:10 ` Thomas Petazzoni
@ 2013-08-02 9:27 ` Thomas De Schampheleire
0 siblings, 0 replies; 32+ messages in thread
From: Thomas De Schampheleire @ 2013-08-02 9:27 UTC (permalink / raw)
To: buildroot
On Fri, Aug 2, 2013 at 11:10 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Fri, 2 Aug 2013 11:09:11 +0200, Thomas De Schampheleire wrote:
>
>> > So the intention is really to have 'make foo-rebuild' do that 'make &&
>> > make install' for the user, for the package <foo>.
>>
>> As said, I don't have a problem with the existing
>> reconfigure-does-it-all approach.
>> I may have misunderstood the objections of others: there is no
>> objection against reconfigure doing also rebuild, only that
>> reconfigure and rebuild also make the rootfs?
>
> That's my understanding of what the objections are, yes.
Ok, in this case I'm fine with changing the situation to handle the
objections, so that if you want to make the rootfs, you explicitly
have to call the 'all' target.
This 'translation table' to mimic the old behavior is still correct, right:
foo-reconfigure --> foo-reconfigure all
foo-rebuild --> foo-rebuild all
Best regards,
Thomas
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-08-02 8:33 ` Thomas De Schampheleire
2013-08-02 8:50 ` Thomas Petazzoni
@ 2013-08-12 21:01 ` Arnout Vandecappelle
1 sibling, 0 replies; 32+ messages in thread
From: Arnout Vandecappelle @ 2013-08-12 21:01 UTC (permalink / raw)
To: buildroot
On 02/08/13 10:33, Thomas De Schampheleire wrote:
> On Thu, Aug 1, 2013 at 11:30 PM, Samuel Martin <s.martin49@gmail.com> wrote:
>> Thomas, all,
>>
>> 2013/8/1 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
>>> Dear Samuel Martin,
>>>
>>> On Thu, 1 Aug 2013 00:13:35 +0200, Samuel Martin wrote:
>>>
>>>> 2013/7/31 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
>>>>
>>>>> http://patchwork.ozlabs.org/patch/243426 Fix bug with dependencies of *-rebuild and *-reconfigure
>>>>> http://patchwork.ozlabs.org/patch/172278 pkg-infra: limit -reconfigure and -rebuild actions
>>>> Both treat the same thing!
>>>> A "political decision" has to be made on this since it slightly
>>>> changes the way some BR commands work.
>>>
>>> Can we have a decision on those ones?
>>>
>>> On my side, I kind of like the fact that 'make blabla-rebuild' both
>>> rebuilds the blabla package and regenerates the root filesystem. It
>>> avoids the need for 'make blabla-rebuild && make'. However, it's true
>>> that it's inconsistent with 'make blabla-dirclean', which just removes
>>> the build directory, and therefore requires a 'make blabla-dirclean &&
>>> make' if you want to completely rebuild a package from scratch.
>>
>> IIRC, we talked about this during some BR dev days or patchwork-day
>> session, and in the end we kept statu quo.
>>
>> I'd rather be in favor of these patches, although I barely use the
>> *-re{configure,build} targets;
I also don't use them because they're not convenient :-) I typically use
make foo-clean-for-rebuild foo
so for me the patch would be really convenient (except that I typically
use several buildroot versions in parallel so I'll forget if I can use
the -rebuild target or not).
>> anyway it's just one opinion among others.
>>
>
> I am currently used to -reconfigure and -rebuild to rebuild also the
> rootfs, but I also agree it's inconsistent with the other targets. If
> we want to be strict, then foo-reconfigure can only configure, not
> build. And foo-rebuild can only build.
> Hence, to get the original behavior of:
> foo-reconfigure --> foo-reconfigure all
> foo-rebuild --> foo-rebuild all
>
> Is that understanding correct?
> As long as we can document this properly, also in the ChangeLog, then
> I'm fine with this semantic change. Adding 'all' isn't the end of the
> world.
BTW the report of the last developer meeting [1] says that we were
going to accept these patches.
Regards,
Arnout
[1] http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013#Action_point_list
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-07-31 17:14 [Buildroot] List of pending patches: what to do? Thomas Petazzoni
` (4 preceding siblings ...)
2013-07-31 22:13 ` Samuel Martin
@ 2013-08-01 2:52 ` Danomi Manchego
2013-08-01 6:13 ` Thomas Petazzoni
2013-08-01 6:54 ` Simon Dawson
` (4 subsequent siblings)
10 siblings, 1 reply; 32+ messages in thread
From: Danomi Manchego @ 2013-08-01 2:52 UTC (permalink / raw)
To: buildroot
> http://patchwork.ozlabs.org/patch/172171 avahi: only install
> default.script/S05avahi-setup.sh if not present in fs skeleton
>
This issue has already been fixed a different way; patch can be discarded.
http://patchwork.ozlabs.org/patch/179493 relative DL_DIR okay?
>
This issue has already been fixed a different way; patch can be discarded.
> http://patchwork.ozlabs.org/patch/198234 group file: define groups
> expected by udev
>
This patch is still good as-is.
> http://patchwork.ozlabs.org/patch/249912 Makefile: change rsync used in
> overlays to always transfer files
>
The patch still applies, with no fuzz but some shifted lines. The problem
described still exists, and is still fixed by the patch.
http://patchwork.ozlabs.org/patch/165382 [1/1] ccache: expose control
> interface via 'make ccache-options'
>
I've no strong objection, but I think that using a Makefile variable to
access the ccache binary is cumbersome, as cumbersome as having to export
a BUILDROOT_CACHE_DIR to get ccache to point to the right directory.
Mercifully, buildroot avoids forcing us to define environment variables
for regular use - for everything except setting up ccache options, that is.
Because of this, I tend to patch ccache to change the last-ditch cache dir
value from "format("%s/.ccache", home_directory)" to the value set in the
.config, which has a much better chance of being correct than
$HOME/.ccache, but can still be overridden by exporting
BUILDROOT_CACHE_DIR. Then output/host/usr/bin/ccache can be invoked
directly to set max-size, stat-clearing, etc. without needing environment
variables.
Danomi -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130731/a8f893b6/attachment.html>
^ permalink raw reply [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-08-01 2:52 ` Danomi Manchego
@ 2013-08-01 6:13 ` Thomas Petazzoni
2013-08-01 20:14 ` Yann E. MORIN
0 siblings, 1 reply; 32+ messages in thread
From: Thomas Petazzoni @ 2013-08-01 6:13 UTC (permalink / raw)
To: buildroot
Dear Danomi Manchego,
On Wed, 31 Jul 2013 22:52:34 -0400, Danomi Manchego wrote:
> > http://patchwork.ozlabs.org/patch/172171 avahi: only install
> > default.script/S05avahi-setup.sh if not present in fs skeleton
> >
>
> This issue has already been fixed a different way; patch can be discarded.
Yep, I've done as part as Gustavo review of the patches.
> http://patchwork.ozlabs.org/patch/179493 relative DL_DIR okay?
>
> This issue has already been fixed a different way; patch can be discarded.
Ok, thanks.
> > http://patchwork.ozlabs.org/patch/198234 group file: define groups
> > expected by udev
>
> This patch is still good as-is.
Patch applied.
> > http://patchwork.ozlabs.org/patch/249912 Makefile: change rsync used in
> > overlays to always transfer files
>
> The patch still applies, with no fuzz but some shifted lines. The problem
> described still exists, and is still fixed by the patch.
It looks good, but I'd like to have someone ACK or test the patch.
Yann, Gustavo, Arnout?
> http://patchwork.ozlabs.org/patch/165382 [1/1] ccache: expose control
> > interface via 'make ccache-options'
>
> I've no strong objection, but I think that using a Makefile variable to
> access the ccache binary is cumbersome
Agreed.
>, as cumbersome as having to export
> a BUILDROOT_CACHE_DIR to get ccache to point to the right directory.
> Mercifully, buildroot avoids forcing us to define environment variables
> for regular use - for everything except setting up ccache options, that is.
> Because of this, I tend to patch ccache to change the last-ditch cache dir
> value from "format("%s/.ccache", home_directory)" to the value set in the
> .config, which has a much better chance of being correct than
> $HOME/.ccache, but can still be overridden by exporting
> BUILDROOT_CACHE_DIR. Then output/host/usr/bin/ccache can be invoked
> directly to set max-size, stat-clearing, etc. without needing environment
> variables.
So the problem is that one cannot simply do
$(O)/host/usr/bin/ccache --max-size=5G
because the BUILDROOT_CACHE_DIR is passed as an environment variable,
and defined by the Buildroot Makefile, so if you want to interact
manually with ccache, you'd have to manually pass BUILDROOT_CACHE_DIR.
This explains why the patch was proposing this CACHE_OPTIONS idea, I
guess. I don't have much other ideas here, though.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-08-01 6:13 ` Thomas Petazzoni
@ 2013-08-01 20:14 ` Yann E. MORIN
0 siblings, 0 replies; 32+ messages in thread
From: Yann E. MORIN @ 2013-08-01 20:14 UTC (permalink / raw)
To: buildroot
Thomas, Danomi, All,
On 2013-08-01 08:13 +0200, Thomas Petazzoni spake thusly:
> On Wed, 31 Jul 2013 22:52:34 -0400, Danomi Manchego wrote:
> > > http://patchwork.ozlabs.org/patch/249912 Makefile: change rsync used in
> > > overlays to always transfer files
> >
> > The patch still applies, with no fuzz but some shifted lines. The problem
> > described still exists, and is still fixed by the patch.
>
> It looks good, but I'd like to have someone ACK or test the patch.
> Yann, Gustavo, Arnout?
I've looked at it, and it indeed seems to be a needed and beneficial
change. I can't think of unexpected adverse side-effect, so I'd
recommend we get it in, but probably in -next just to be extra safe.
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-07-31 17:14 [Buildroot] List of pending patches: what to do? Thomas Petazzoni
` (5 preceding siblings ...)
2013-08-01 2:52 ` Danomi Manchego
@ 2013-08-01 6:54 ` Simon Dawson
2013-08-01 7:41 ` Thomas Petazzoni
2013-08-01 16:16 ` Thomas Petazzoni
` (3 subsequent siblings)
10 siblings, 1 reply; 32+ messages in thread
From: Simon Dawson @ 2013-08-01 6:54 UTC (permalink / raw)
To: buildroot
On 31 July 2013 18:14, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> http://patchwork.ozlabs.org/patch/165674 [RFC,1/2] Add configuration item for custom JavaScript install path
> http://patchwork.ozlabs.org/patch/165675 [RFC,2/2] Use JavaScript install path from configuration during package installation
These can be discarded now, as I have no intention of working on them further.
> http://patchwork.ozlabs.org/patch/213384 [RFC] Fix avr32 build using internal toolchain
No longer relevant, as uClibc 0.9.31 support has now been removed from
Buildroot. Can be discarded.
> http://patchwork.ozlabs.org/patch/236409 udev: fix avr32 and microblaze build failures
I haven't noticed any avr32/microblaze udev autobuild failures for a
while... I suggest that this patch be discarded.
> http://patchwork.ozlabs.org/patch/238366 [RFC] permit menu customization
This doesn't adequately solve the problem that it sets out to solve;
can be discarded. (Although I do think this is still an area in which
Buildroot could be improved.)
Simon.
^ permalink raw reply [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-08-01 6:54 ` Simon Dawson
@ 2013-08-01 7:41 ` Thomas Petazzoni
0 siblings, 0 replies; 32+ messages in thread
From: Thomas Petazzoni @ 2013-08-01 7:41 UTC (permalink / raw)
To: buildroot
Dear Simon Dawson,
On Thu, 1 Aug 2013 07:54:33 +0100, Simon Dawson wrote:
> On 31 July 2013 18:14, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > http://patchwork.ozlabs.org/patch/165674 [RFC,1/2] Add configuration item for custom JavaScript install path
> > http://patchwork.ozlabs.org/patch/165675 [RFC,2/2] Use JavaScript install path from configuration during package installation
>
> These can be discarded now, as I have no intention of working on them further.
Thanks, done.
> > http://patchwork.ozlabs.org/patch/213384 [RFC] Fix avr32 build using internal toolchain
>
> No longer relevant, as uClibc 0.9.31 support has now been removed from
> Buildroot. Can be discarded.
Done.
> > http://patchwork.ozlabs.org/patch/236409 udev: fix avr32 and microblaze build failures
>
> I haven't noticed any avr32/microblaze udev autobuild failures for a
> while... I suggest that this patch be discarded.
Most likely we have upgraded the avr32 and microblaze toolchains since
then, and that's why we're not seeing the issues anymore. I've
discarded the patch.
> > http://patchwork.ozlabs.org/patch/238366 [RFC] permit menu customization
>
> This doesn't adequately solve the problem that it sets out to solve;
> can be discarded. (Although I do think this is still an area in which
> Buildroot could be improved.)
I agree it's an area in which Buildroot could be improved. I've dropped
the patch for now, as you suggested.
Thanks for this review!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-07-31 17:14 [Buildroot] List of pending patches: what to do? Thomas Petazzoni
` (6 preceding siblings ...)
2013-08-01 6:54 ` Simon Dawson
@ 2013-08-01 16:16 ` Thomas Petazzoni
2013-08-02 8:10 ` Jérôme Pouiller
` (2 subsequent siblings)
10 siblings, 0 replies; 32+ messages in thread
From: Thomas Petazzoni @ 2013-08-01 16:16 UTC (permalink / raw)
To: buildroot
Hello,
Thanks to all the people who participated to this thread.
On Wed, 31 Jul 2013 19:14:15 +0200, Thomas Petazzoni wrote:
> We currently have 228 pending patches in our patchwork at
> http://patchwork.ozlabs.org/project/buildroot/list/. Many patches are
As of now, we're down to 198 patches. Do not hesitate to continue to
comment on patches, or adopt some of them. Even though I'll release
-rc1 tomorrow, I'll continue to take 'invasive' patches since I'll open
-next immediately after -rc1 opens.
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 [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-07-31 17:14 [Buildroot] List of pending patches: what to do? Thomas Petazzoni
` (7 preceding siblings ...)
2013-08-01 16:16 ` Thomas Petazzoni
@ 2013-08-02 8:10 ` Jérôme Pouiller
2013-08-02 11:11 ` Patrick Ziegler
2013-08-19 10:35 ` Luca Ceresoli
10 siblings, 0 replies; 32+ messages in thread
From: Jérôme Pouiller @ 2013-08-02 8:10 UTC (permalink / raw)
To: buildroot
Hi,
On 2013-07-31 19:14, Thomas Petazzoni wrote:
[...]
> http://patchwork.ozlabs.org/patch/219795 lxc: new package
Not intrusive and works for me. Let's see if autobuilder throw
anything.
[...]
> http://patchwork.ozlabs.org/patch/243426 Fix bug with dependencies of
> *-rebuild and *-reconfigure
There is another discussion thread about this patch (I am also in favor
of its integration).
> http://patchwork.ozlabs.org/patch/243427 [v2] Add support for plain
> URL in $(PKG)_PATCH variable
Hmmm... reviewed by Yann and Markos. Could be merged, isn't?
[...]
> http://patchwork.ozlabs.org/patch/243725 Standardisation of
> $(BUILD)/.root name
I have to send a last update of this patch
--
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr
^ permalink raw reply [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-07-31 17:14 [Buildroot] List of pending patches: what to do? Thomas Petazzoni
` (8 preceding siblings ...)
2013-08-02 8:10 ` Jérôme Pouiller
@ 2013-08-02 11:11 ` Patrick Ziegler
2013-08-02 11:17 ` Thomas Petazzoni
2013-08-19 10:35 ` Luca Ceresoli
10 siblings, 1 reply; 32+ messages in thread
From: Patrick Ziegler @ 2013-08-02 11:11 UTC (permalink / raw)
To: buildroot
Hi,
On 31.07.2013 19:14, Thomas Petazzoni wrote:
> http://patchwork.ozlabs.org/patch/220720 Using external toolchain wrapper outside of buildroot
Fixed with another commit (74ae7af927)
Patrick
--
Dipl.-Inf. (FH) Patrick Ziegler
University Of Applied Sciences
Kaiserslautern
Amerikastrasse 1
D-66482 Zweibruecken
Germany
Phone: +49 631 3724 5526
Mail: patrick.ziegler at fh-kl.de
PGP KeyID 0xB4796B8C
http://www.fh-kl.de
http://www.fh-kl.de/fachbereiche/imst/iuk-knowhow.html
^ permalink raw reply [flat|nested] 32+ messages in thread* [Buildroot] List of pending patches: what to do?
2013-08-02 11:11 ` Patrick Ziegler
@ 2013-08-02 11:17 ` Thomas Petazzoni
0 siblings, 0 replies; 32+ messages in thread
From: Thomas Petazzoni @ 2013-08-02 11:17 UTC (permalink / raw)
To: buildroot
Dear Patrick Ziegler,
On Fri, 2 Aug 2013 13:11:23 +0200, Patrick Ziegler wrote:
> On 31.07.2013 19:14, Thomas Petazzoni wrote:
>
> > http://patchwork.ozlabs.org/patch/220720 Using external toolchain wrapper outside of buildroot
>
> Fixed with another commit (74ae7af927)
Thanks, marked as Superseded!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] List of pending patches: what to do?
2013-07-31 17:14 [Buildroot] List of pending patches: what to do? Thomas Petazzoni
` (9 preceding siblings ...)
2013-08-02 11:11 ` Patrick Ziegler
@ 2013-08-19 10:35 ` Luca Ceresoli
10 siblings, 0 replies; 32+ messages in thread
From: Luca Ceresoli @ 2013-08-19 10:35 UTC (permalink / raw)
To: buildroot
Thomas,
Thomas Petazzoni wrote:
> Hello,
>
> We currently have 228 pending patches in our patchwork at
> http://patchwork.ozlabs.org/project/buildroot/list/. Many patches are
> old and should be adopted to be cleaned up and resubmitted, or maybe
> need to be rejected but after some community discussion.
>
> In order to help reducing the backlog of patches, I'm pasting below the
> entire list of patches with their title and direct link to patchwork.
> What I'm interested in is people replying to this e-mail and giving
> their opinion about some of the patches (don't try to look at all of
> them, but at least a few of them). Opinions can be: we should reject,
> I'm interested in adopting the patch and refreshing it, the patch is
> interesting but needs this and that to be merged, etc.
>
> Thanks for your help!
...
> http://patchwork.ozlabs.org/patch/230289 [v2] Enable ccache for cmake packages
This led to a fairly long discussion with Samuel, you and me on howit
should be implemented.You suggested it should be done in the toolchain
wrappers. Thedetails were not clear to me, but it was definitely nothing
similar to this patch.
So probably it should be dropped from patchwork.
Note: the discussion is not fully visible in patchwork, see it here:
http://lists.busybox.net/pipermail/buildroot/2013-March/068306.html
FWIW, I'm not even using that patch. Instead I'm using the v1
(http://lists.busybox.net/pipermail/buildroot/2013-March/068306.html)
which added a stupid shell wrapper around TARGET_CC/_CXX. It's probably
not very nice but it's simple and it just works.
Luca
^ permalink raw reply [flat|nested] 32+ messages in thread