[Buildroot] List of pending patches: what to do?

[Thomas Petazzoni]

Dear Samuel Martin,

On Thu, 1 Aug 2013 00:13:35 +0200, Samuel Martin wrote:

> 2013/7/31 Thomas Petazzoni <thomas.petazzoni at 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