From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Markus Mayer <mmayer@broadcom.com>
Cc: Julien Olivain <ju.o@free.fr>, Bernd Kuhls <bernd@kuhls.net>,
Buildroot List <buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH 1/1] package/e2fsprogs: fix fsverity build error slightly differently
Date: Mon, 2 Feb 2026 14:18:45 +0100 [thread overview]
Message-ID: <aYCjvj6p819w-_E7@windsurf> (raw)
In-Reply-To: <20251205003008.153577-2-mmayer@broadcom.com>
Hello Markus,
On Thu, Dec 04, 2025 at 04:30:04PM -0800, Markus Mayer via buildroot wrote:
> Turns out Thomas and I were working concurrently on two different ways
> to fix the e2fsprogs 1.47.3 build error with regards to fsverity not
> being present in older kernels.
>
> Thomas' patch disables the fsverity functionality in e2fsprogs based on
> the kernel headers used for compilation while my patch aims to provide
> the missing definitions if the kernel doesn't.
>
> By providing the missing definitions whenever the kernel headers don't,
> fsverity related features can be compiled in even if the kernel headers
> are too old. This allows binaries to run on newer kernels with full
> functionality, but it relies on e2fsprogs to properly handle -ENOTSUPP
> errors at runtime if the kernel doesn't support the ioctl.[1]
>
> We both submitted our respective patches to Ted T'so but haven't heard
> back as of yet. After a brief discussion on the Buildroot mailing list,
> we are trying my approach for now.
>
> [1]: Compiling binaries against older kernel headers, but exclusively
> running them on newer kernels, can happen if one's toolchain comes with
> older kernel headers in the sysroot for increased compatibility across
> multiple kernel versions (e.g. the same toolchain & sysroot are used to
> build root file systems with Linux 5.4 and 6.12).
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Since then, my patch has been accepted and merged by Ted Tso:
https://github.com/tytso/e2fsprogs/commit/4aba12dc19a95626eb7fa1df2d19c5235c2bc848
And it was integrated into Buildroot as well. Since we no longer have
any build failure in Buildroot, I think to be convinced that another
approach is needed, you should first convince upstream first that your
approach is better. Therefore, I will mark your Buildroot patch as
Rejected, but if you get your patches merged upstream, we will
obviously be happy to backport them in Buildroot (until a new
e2fsprogs release contains them, of course).
Best regards,
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
prev parent reply other threads:[~2026-02-02 13:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-05 0:30 [Buildroot] [PATCH 0/1] package/e2fsprogs: fix fsverity build error slightly differently Markus Mayer via buildroot
2025-12-05 0:30 ` [Buildroot] [PATCH 1/1] " Markus Mayer via buildroot
2026-02-02 13:18 ` Thomas Petazzoni 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=aYCjvj6p819w-_E7@windsurf \
--to=buildroot@buildroot.org \
--cc=bernd@kuhls.net \
--cc=ju.o@free.fr \
--cc=mmayer@broadcom.com \
--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 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.