Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Peter Korsgaard <peter@korsgaard.com>
Cc: Julien Olivain <ju.o@free.fr>, Fiona Klute <fiona.klute@gmx.de>,
	Romain Naour <romain.naour@smile.fr>,
	Fiona Klute via buildroot <buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH 1/1] Makefile: add check-package-external target
Date: Sun, 4 Jan 2026 11:39:24 +0100	[thread overview]
Message-ID: <20260104113924.204d1799@windsurf> (raw)
In-Reply-To: <87wm1xn0sp.fsf@dell.be.48ers.dk>

On Sun, 04 Jan 2026 11:13:10 +0100
Peter Korsgaard <peter@korsgaard.com> wrote:

> Sorry, didn't look at the patch yet, but could we instead make 'make
> check-package' do the right thing if BR2_EXTERNAL is non-zero? E.G.
> iterate over the words in it (and pass --br2-external to check-package)?

There was some rationale in Fiona's patch about why it wasn't done like
this, though maybe this is something we want to challenge.

Here is the rationale:

"""

I've considered wrapping this into the existing check-package target,
but there are a few reasons not to:

1. Some people might not want to subject their external trees to
check-package at all, and would be annoyed by the warnings.

2. BR2_EXTERNAL support for utils/docker-run is still pending (see [1]).

3. The older shellcheck and flake8 versions in the Buildroot base
container image used by utils/docker-run produce some false positives
for my external trees, so I want to keep using the (newer) local
versions for checking those, but use the container for upstream
patches. That is more convenient with separate targets.
"""

Still maybe we should consider ensuring that check-package validates
BR2_EXTERNAL, and somehow address these concerns?

I think (1) is pretty moot, if you're not concerned about check-package
warnings, don't run it at all.

Regarding (2): probably a matter of merging BR2_EXTERNAL support for
docker-run.

Regarding (3): we could also update our Docker container.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2026-01-04 14:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-29  9:24 [Buildroot] [PATCH 1/1] Makefile: add check-package-external target Fiona Klute via buildroot
2026-01-01 17:18 ` Thomas Petazzoni via buildroot
2026-01-01 18:04   ` Fiona Klute via buildroot
2026-01-04 10:13   ` Peter Korsgaard
2026-01-04 10:39     ` Thomas Petazzoni via buildroot [this message]
2026-01-04 13:34       ` Peter Korsgaard
2026-01-12 21:02         ` Fiona Klute via buildroot
2026-02-03 10:40 ` Arnout Vandecappelle via buildroot
2026-02-13 19:37 ` Thomas Perale via buildroot

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=20260104113924.204d1799@windsurf \
    --to=buildroot@buildroot.org \
    --cc=fiona.klute@gmx.de \
    --cc=ju.o@free.fr \
    --cc=peter@korsgaard.com \
    --cc=romain.naour@smile.fr \
    --cc=thomas.petazzoni@bootlin.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox