Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen via buildroot <buildroot@buildroot.org>
To: Fiona Klute <fiona.klute@gmx.de>
Cc: stefanb@linux.ibm.com, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/3] package/libtpms: fix typo in HOST_LIBTPMS_CONF_OPTS
Date: Thu, 15 Oct 2026 06:02:36 +0300	[thread overview]
Message-ID: <atBCTG3NFPdhhIDr@kernel.org> (raw)
In-Reply-To: <b6a925a4-9eae-4193-b3aa-06f9755aeb89@gmx.de>

On Wed, Oct 14, 2026 at 10:52:53PM +0200, Fiona Klute wrote:
> Am 14.10.26 um 22:38 schrieb Jarkko Sakkinen:
> > On Wed, Oct 14, 2026 at 06:46:23PM +0200, Fiona Klute wrote:
> > > From: "Fiona Klute (othermo GmbH)" <fiona.klute@gmx.de>
> > > 
> > > --with-... arguments need two dashes.
> > > 
> > > Fixes: b2eec8c6265a38cdba1afadf7f60e0fd00f3b448
> > > 
> > 
> > By defacto there's no new line here, and it's 12 most significant
> > bytes of the hash and short summary in parentheses. This is at
> > least how it has always been in Linux but not 100% sure about
> > Buildroot. It just looks weird to me.
> > 
> > E.g., I would instead:
> > 
> > Fixes: b2eec8c6265a ("package/libtpms: add host package")
> > 
> > And wold not add the newline. Since this is not kernel, take
> > with a grain of salt.
> 
> In Buildroot we don't have a defined style for this, but use a newline more
> often then not. Personally I find shortened commit IDs irritating, anyway.

Not recall challenging any particular convention. Listing what you know
and what you don't know and underlining that your facts could be wrong
does not go into that basket.

I.e. if you like how you do it, I'm not standing in the way, or have
not been.

> 
> > > Signed-off-by: Fiona Klute (othermo GmbH) <fiona.klute@gmx.de>
> > > ---
> > >   package/libtpms/libtpms.mk | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/package/libtpms/libtpms.mk b/package/libtpms/libtpms.mk
> > > index 7bc69a50d6..0ece84ae04 100644
> > > --- a/package/libtpms/libtpms.mk
> > > +++ b/package/libtpms/libtpms.mk
> > > @@ -13,6 +13,6 @@ LIBTPMS_INSTALL_STAGING = YES
> > >   # Required because a plain Git clone is used:
> > >   HOST_LIBTPMS_AUTORECONF = YES
> > >   HOST_LIBTPMS_DEPENDENCIES = host-pkgconf host-openssl
> > > -HOST_LIBTPMS_CONF_OPTS = --with-openssl  -with-tpm2
> > > +HOST_LIBTPMS_CONF_OPTS = --with-openssl --with-tpm2
> > >   $(eval $(host-autotools-package))
> > > -- 
> > > 2.55.0
> > > 
> > 
> > I'm not saying this is not right but I'm neither sure whether this
> > is bug fix or not.
> > 
> > This is a weird because I've used this almost on a daily basis for
> > Linux kernel QA since I contributed this... Stefan can you help out
> > resolving the mystery?
> I assume it wasn't noticeable because tpm2 support being enabled is the
> default anyway. But we like setting options explicitly in Buildroot. ;-)

It was unnoticeable because you did not write it to the commit message.

Honestly: I do not care what you think about Buildroot options because
I do not have an opinion. Please stop framing me. Thank you.

> 
> Best regards,
> Fiona

Br, Jarkko
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

      reply	other threads:[~2026-10-15  3:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14 16:46 [Buildroot] [PATCH 1/3] package/libtpms: fix typo in HOST_LIBTPMS_CONF_OPTS Fiona Klute via buildroot
2026-10-14 16:46 ` [Buildroot] [PATCH 2/3] package/libtpms: disable building manpages Fiona Klute via buildroot
2026-10-15  3:09   ` Jarkko Sakkinen via buildroot
2026-10-14 16:46 ` [Buildroot] [PATCH 3/3] package/swtpm: " Fiona Klute via buildroot
2026-10-15  3:10   ` Jarkko Sakkinen via buildroot
2026-10-14 20:38 ` [Buildroot] [PATCH 1/3] package/libtpms: fix typo in HOST_LIBTPMS_CONF_OPTS Jarkko Sakkinen via buildroot
2026-10-14 20:52   ` Fiona Klute via buildroot
2026-10-15  3:02     ` Jarkko Sakkinen via buildroot [this message]

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=atBCTG3NFPdhhIDr@kernel.org \
    --to=buildroot@buildroot.org \
    --cc=fiona.klute@gmx.de \
    --cc=jarkko@kernel.org \
    --cc=stefanb@linux.ibm.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