All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] List of pending patches: what to do?
Date: Thu, 1 Aug 2013 08:13:03 +0200	[thread overview]
Message-ID: <20130801081303.4d1570aa@skate> (raw)
In-Reply-To: <CANxTyt5V08njumRpKWQJEqThgd_FUKYnjg+XLwbFbWk+MKvx6Q@mail.gmail.com>

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

  reply	other threads:[~2013-08-01  6:13 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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-08-01  5:39     ` Thomas Petazzoni
2013-07-31 17:51 ` Gustavo Zacarias
2013-08-01  5:50   ` Thomas Petazzoni
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
2013-07-31 20:55 ` Yann E. MORIN
2013-08-01  6:04   ` Thomas Petazzoni
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
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-02  9:10             ` Thomas Petazzoni
2013-08-02  9:27               ` Thomas De Schampheleire
2013-08-12 21:01         ` Arnout Vandecappelle
2013-08-01  2:52 ` Danomi Manchego
2013-08-01  6:13   ` Thomas Petazzoni [this message]
2013-08-01 20:14     ` Yann E. MORIN
2013-08-01  6:54 ` Simon Dawson
2013-08-01  7:41   ` Thomas Petazzoni
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-02 11:17   ` Thomas Petazzoni
2013-08-19 10:35 ` Luca Ceresoli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130801081303.4d1570aa@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.