Hi Simon,
On 5/4/26 2:16 PM, Simon Glass wrote:
Hi,
As you know, I maintain several tools which are part of the U-Boot tree.
Tom has previously suggested that it would be better to move patman
out of the U-Boot tree, e.g. to its own Github project. It is a
general tool which can be used with Linux and other
mailing-list/patchwork-based projects. I have never been keen on
taking on the extra effort required, but I've recently added more
features and am wondering whether now might be a good time to do this.
Even before b4 got released, I've never used patman, so I don't know
what I'm missing out on but b4 has fixed all the gripes I had with
git-format-patch+git-send-email so far.
What I can say though is that I cannot install the requirements for
running tests on Fedora, for a few releases already, because patman is
using an old pygit2 which doesn't compile with newer versions of libgit2.
Building wheels for collected packages: pygit2
Building wheel for pygit2 (pyproject.toml) ... error
error: subprocess-exited-with-error
× Building wheel for pygit2 (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [75 lines of output]
running bdist_wheel
running build
running build_py
creating build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/utils.py -> build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/submodules.py ->
build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/settings.py ->
build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/repository.py ->
build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/remotes.py ->
build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/refspec.py ->
build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/references.py ->
build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/packbuilder.py ->
build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/legacyenums.py ->
build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/index.py -> build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/filter.py -> build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/ffi.py -> build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/errors.py -> build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/enums.py -> build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/credentials.py ->
build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/config.py -> build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/callbacks.py ->
build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/branches.py ->
build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/blob.py -> build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/blame.py -> build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/_run.py -> build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/_build.py -> build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/__init__.py ->
build/lib.linux-x86_64-cpython-314/pygit2
copying pygit2/_pygit2.pyi ->
build/lib.linux-x86_64-cpython-314/pygit2
creating build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/types.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/transport.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/submodule.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/strarray.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/stash.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/revert.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/repository.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/remote.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/refspec.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/proxy.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/pack.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/oid.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/net.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/merge.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/indexer.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/index.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/graph.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/errors.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/diff.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/describe.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/config.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/common.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/commit.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/clone.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/checkout.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/callbacks.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/buffer.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/blame.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
copying pygit2/decl/attr.h ->
build/lib.linux-x86_64-cpython-314/pygit2/decl
running build_ext
generating cffi module
'build/temp.linux-x86_64-cpython-314/pygit2._libgit2.c'
creating build/temp.linux-x86_64-cpython-314
building 'pygit2._pygit2' extension
creating
build/temp.linux-x86_64-cpython-314/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src
gcc -fno-strict-overflow -Wsign-compare
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -fexceptions -fcf-protection
-fexceptions -fcf-protection -fexceptions -fcf-protection -O3 -fPIC
-I/usr/local/include -I/home/qschulz/work/upstream/u-boot/venv/include
-I/usr/include/python3.14 -c
/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/blob.c
-o
build/temp.linux-x86_64-cpython-314/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/blob.o
In file included from
/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/diff.h:34,
from
/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/blob.c:31:
/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/types.h:37:2:
error: #error You need a compatible libgit2 version (1.7.x)
37 | #error You need a compatible libgit2 version (1.7.x)
| ^~~~~
/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/blob.c:
In function ‘blob_filter_stream_write’:
/tmp/pip-install-sg4tws_1/pygit2_dfcf87fabf704024a62ab6e9ec4033ed/src/blob.c:171:13:
error: implicit declaration of function ‘git_error_set’; did you mean
‘git_error_last’? [-Wimplicit-function-declaration]
171 | git_error_set(GIT_ERROR_OS, "failed to put
chunk to queue");
| ^~~~~~~~~~~~~
| git_error_last
error: command '/usr/lib64/ccache/gcc' failed with exit code 1
[end of output]
note: This error originates from a subprocess, and is likely not a
problem with pip.
ERROR: Failed building wheel for pygit2
Failed to build pygit2
and this essentially has requested I run the tests within the CI
container, which I would prefer not to do if possible (I somehow managed
to break my U-Boot local git repo once doing that).
Buildman is quite obviously designed specifically for U-Boot. I have
made some improvements recently (a large code refactor and distributed
builds). I would like to push those changes to mainline. Do people
think it should be in a separate tree somewhere?
I've only started to use buildman when I did tree-wide refactoring and
needed to make sure I didn't break anything. It's however essential in
CI. I don't think it's actively being developed at the moment (at least
publicly in U-Boot ML) so maybe that's good enough?
Considering the changes made in your fork are as far as I could tell
mostly developed by/with LLMs and that Tom has been pretty vocal against
it, moving it outside of the U-Boot umbrella and thus lose "control" of
what can or cannot be merged while still making use of it in U-Boot
seems like something we may not want to do.
Binman was written with U-Boot in mind but supports other projects
(such as Zephyr). It is generic enough that it could be separated. The
impact would be harder code review.
Is Binman actually currently used outside of U-Boot? It's one thing to
support building other projects but if those projects aren't actually
using it, I'm not sure it's a strong argument (though, the fact it's in
U-Boot tree could be a major obstacle for other projects to easily
incorporate it in their process).
Considering binman is an essential piece of SW for some architectures
(e.g. Rockchip), I don't know if it makes sense to separate it right
now. At least I don't see an immediate need for splitting it.
We also have smaller things like qconfig (which I have substantially
rewritten to make it fast) and dtoc, which is very tailored to U-Boot.
I think qconfig is used every now and then by Tom and it was helpful to
me when doing refactoring and symbol renaming. It's lacking a feature
for me but saw your article on qconfig being rewritten in your fork so
was wondering whether to look at it now or if it would make it to the
U-Boot ML at some point.
The feature I've found myself really wanting is to filter configs based
on a symbol and then print the value of some symbols.
E.g. I've wanted in
https://lore.kernel.org/u-boot/[email protected]/
to know what was the value of CONFIG_SYS_RX_ETH_BUFFER when
CONFIG_FSL_ENETC is enabled. Same for CONFIG_TI_K3_NAVSS_UDMA and
CONFIG_SYS_RX_ETH_BUFFER.
I don't think qconfig is an essential tool for U-Boot and could probably
live outside of U-Boot. I believe the feature of this tool would be
useful for any project using Kconfig (Linux kernel, Zephyr, U-Boot,
Barebox, etc...). It however depends on buildman and u-boot pylib today,
so maybe it's unnecessary complexity to move it out of U-Boot for now
(and also makes it unusable for other projects?). I don't think there's
a hurry moving this one to a different place, it's not really bothering
me to have it in-tree.
What do people think? Of all of these, patman would be the easiest to
move, with the least impact on existing workflows.
I think starting with patman would be nice :)
Cheers,
Quentin
