From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Fri, 10 Oct 2014 04:23:02 +0200
Subject: [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force
	parameter to stdio_deregister
In-Reply-To: <CAPnjgZ2-fyKVOn0VQmgjXmeRsKS6+k7BYzhkyiXTBUi88RBnXA@mail.gmail.com>
References: <1411224878-13692-1-git-send-email-hdegoede@redhat.com>
	<201410100159.37681.marex@denx.de>
	<CAPnjgZ2-fyKVOn0VQmgjXmeRsKS6+k7BYzhkyiXTBUi88RBnXA@mail.gmail.com>
Message-ID: <201410100423.02346.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Friday, October 10, 2014 at 04:00:00 AM, Simon Glass wrote:
> Hi Marek,
> 
> On 9 October 2014 17:59, Marek Vasut <marex@denx.de> wrote:
> > On Thursday, October 09, 2014 at 08:04:29 PM, Simon Glass wrote:
> >> Hi Marek,
> > 
> > Hi Simon,
> > 
> > [..]
> > 
> >> > I mean more continuous integration (build testing) of the code before
> >> > a PR is submitted to the ML. Right now, we all do our own thing when
> >> > it comes to testing before PR, but it would be nice to have one easy
> >> > way of doing the build testing before submitting the PR, don't you
> >> > think ? This might apply to Linux too.
> >> 
> >> Sure it would be useful. Before submitting my pull request I get all the
> >> patches in a branch and run:
> >> 
> >> ./tools/buildman/buildman -b x86-push
> >> 
> >> This checks every commit for every board that I build, and gives me good
> >> confidence that no patch introduces new breakages.
> > 
> > I agree that buildman solves the CI part nicely, but we also have the
> > part where one has to install the myriad of toolchains for all the
> > architectures to be able to do the compile testing. I wonder if this
> > cannot be made easy in some way -- maybe through a re-usable docker
> > image with all the parts in it already.
> 
> It would be create if we could download all the toolchains from one
> place. Maybe we need a toolchain maintainer?

What about [1], this is where we can source the more exotic toolchains from,
can we not? I think it was even you who pointed me to this site and it really
is a nice one ;-)

[1] https://www.kernel.org/pub/tools/crosstool/

Best regards,
Marek Vasut