Message ID | 20240506144555.31709-1-ps.report@gmx.net |
---|---|
Headers | show |
Series | support/kconfig: bump to linux-v6.9-rc5 version | expand |
Hello, On Mon, 6 May 2024 16:45:43 +0200 Peter Seiderer via buildroot <buildroot@buildroot.org> wrote: > The patches are orderd by the first 5 handling some minor nits (result of > the new kconfig beeing a little more strict about the syntax, can be > applied in advance): > > - boot/barebox/Config.in: source argument needs quotation marks > - package/cmocka/Config.in: bool argument needs quotation marks > - package/dovecot/Config.in: source argument needs quotation marks > - package/python-pydal/Config.in: bool argument needs quotation marks > - package/x11r7/Config.in: source argument needs quotation marks I have applied those preparation patches that make sense regardless of what happens with the bump. > The kconfig version dump itself: > > - support/kconfig: bump to linux-v6.9-rc5 version So this commit without the next two leads to a broken situation, correct? (Note: this is not a complaint, I agree with them being split). > And two 'real' changes due to kconfig language changes: > > - support/kconfig: reference environment variables directly (remove 'option env=') > - package/openssl: move libopenssl/libressl source statemetns outside of the choice But don't we have this situation of source statements inside a choice..endchoice in other places? I remember Yann saying that this was a problematic change for us in the upstream kconfig code. Best regards, Thomas
Thomas, Peter, All, On 2024-05-06 21:04 +0200, Thomas Petazzoni via buildroot spake thusly: > On Mon, 6 May 2024 16:45:43 +0200 > Peter Seiderer via buildroot <buildroot@buildroot.org> wrote: [--SNIP--] > > The kconfig version dump itself: > > - support/kconfig: bump to linux-v6.9-rc5 version > So this commit without the next two leads to a broken situation, > correct? (Note: this is not a complaint, I agree with them being split). Except they should be reversed: the new commits can work with the kconfig we currently have, so it looks like it should be OK to do the required changes before doing the kconfig bump. > > And two 'real' changes due to kconfig language changes: > > - support/kconfig: reference environment variables directly (remove 'option env=') > > - package/openssl: move libopenssl/libressl source statemetns outside of the choice > But don't we have this situation of source statements inside a > choice..endchoice in other places? Toolchains, skeletons, init systems, jpeg library, linux extensions, and indeed openssl. > I remember Yann saying that this was > a problematic change for us in the upstream kconfig code. Yes, so given that there are two problematic changes: - source statements in choices, - environment variable direct expansion, I wonder if it makes sense for us to update our kconfig infra... Regards, Yann E. MORIN.
On Mon, 6 May 2024 22:19:39 +0200 "Yann E. MORIN" <yann.morin.1998@free.fr> wrote: > > So this commit without the next two leads to a broken situation, > > correct? (Note: this is not a complaint, I agree with them being split). > > Except they should be reversed: the new commits can work with the > kconfig we currently have, so it looks like it should be OK to do the > required changes before doing the kconfig bump. I don't think the logic changed in "support/kconfig: reference environment variables directly (remove 'option env=')" can work with the current kconfig code base. > > I remember Yann saying that this was > > a problematic change for us in the upstream kconfig code. > > Yes, so given that there are two problematic changes: > - source statements in choices, > - environment variable direct expansion, > I wonder if it makes sense for us to update our kconfig infra... But we'd hate to stay stuck on an old kconfig code base forever. Gtk is going to move on, Qt is going to move on, which means at some point in the future, our "make xconfig" and "make gconfig" would no longer work. Thomas
Hello Thomas, On Mon, 6 May 2024 21:04:40 +0200, Thomas Petazzoni via buildroot <buildroot@buildroot.org> wrote: > Hello, > > On Mon, 6 May 2024 16:45:43 +0200 > Peter Seiderer via buildroot <buildroot@buildroot.org> wrote: > > > The patches are orderd by the first 5 handling some minor nits (result of > > the new kconfig beeing a little more strict about the syntax, can be > > applied in advance): > > > > - boot/barebox/Config.in: source argument needs quotation marks > > - package/cmocka/Config.in: bool argument needs quotation marks > > - package/dovecot/Config.in: source argument needs quotation marks > > - package/python-pydal/Config.in: bool argument needs quotation marks > > - package/x11r7/Config.in: source argument needs quotation marks > > I have applied those preparation patches that make sense regardless of > what happens with the bump. Thanks... > > > The kconfig version dump itself: > > > > - support/kconfig: bump to linux-v6.9-rc5 version > > So this commit without the next two leads to a broken situation, > correct? (Note: this is not a complaint, I agree with them being split). Yes, but the next two patches can eventually squashed with this one, but did keep separate for better patch review/iteration (suspected some more discussion on this ones)... > > > And two 'real' changes due to kconfig language changes: > > > > - support/kconfig: reference environment variables directly (remove 'option env=') > > - package/openssl: move libopenssl/libressl source statemetns outside of the choice > > But don't we have this situation of source statements inside a > choice..endchoice in other places? I remember Yann saying that this was > a problematic change for us in the upstream kconfig code. Yes, that is the reasoning for the (suggested by Yann) patches/23-Revert-kconfig-allow-only-config-comment-and-if-insi.patch With this one reverted I get the following warnings/errors: toolchain/toolchain-external/Config.in:12: syntax error toolchain/toolchain-external/Config.in:12: invalid statement toolchain/toolchain-external/Config.in:13: invalid statement toolchain/toolchain-external/Config.in:16: invalid statement toolchain/toolchain-external/Config.in:17: invalid statement toolchain/toolchain-external/Config.in:20: invalid statement toolchain/toolchain-external/Config.in:23: invalid statement toolchain/toolchain-external/Config.in:24: invalid statement toolchain/toolchain-external/Config.in:27: invalid statement toolchain/toolchain-external/Config.in:30: invalid statement toolchain/toolchain-external/Config.in:33: invalid statement toolchain/toolchain-external/Config.in:38: invalid statement toolchain/toolchain-external/Config.in:41: invalid statement system/Config.in:23: syntax error system/Config.in:23: invalid statement system/Config.in:157: syntax error system/Config.in:157: invalid statement package/openssl/Config.in:46: syntax error package/openssl/Config.in:46: invalid statement package/jpeg/Config.in:43: syntax error package/jpeg/Config.in:43: invalid statement With the patch the remaining problematic source-inside-choice are in package/openssl/Config.in, seems not all content is allowed to be included... Regards, Peter > > Best regards, > > Thomas
Hello Yann, Thomas, On Mon, 6 May 2024 22:19:39 +0200, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote: > Thomas, Peter, All, > > On 2024-05-06 21:04 +0200, Thomas Petazzoni via buildroot spake thusly: > > On Mon, 6 May 2024 16:45:43 +0200 > > Peter Seiderer via buildroot <buildroot@buildroot.org> wrote: > [--SNIP--] > > > The kconfig version dump itself: > > > - support/kconfig: bump to linux-v6.9-rc5 version > > So this commit without the next two leads to a broken situation, > > correct? (Note: this is not a complaint, I agree with them being split). > > Except they should be reversed: the new commits can work with the > kconfig we currently have, so it looks like it should be OK to do the > required changes before doing the kconfig bump. A solution for the two remaining patches working with the old/new kconfig would be nice..., will test if it works for the escape problem... Regards, Peter > > > > And two 'real' changes due to kconfig language changes: > > > - support/kconfig: reference environment variables directly (remove 'option env=') > > > - package/openssl: move libopenssl/libressl source statemetns outside of the choice > > But don't we have this situation of source statements inside a > > choice..endchoice in other places? > > Toolchains, skeletons, init systems, jpeg library, linux extensions, and > indeed openssl. > > > I remember Yann saying that this was > > a problematic change for us in the upstream kconfig code. > > Yes, so given that there are two problematic changes: > - source statements in choices, > - environment variable direct expansion, > I wonder if it makes sense for us to update our kconfig infra... > > Regards, > Yann E. MORIN. >
Peter, All, On 2024-05-08 17:21 +0200, Peter Seiderer via buildroot spake thusly: > On Mon, 6 May 2024 22:19:39 +0200, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote: > > On 2024-05-06 21:04 +0200, Thomas Petazzoni via buildroot spake thusly: > > > On Mon, 6 May 2024 16:45:43 +0200 > > > Peter Seiderer via buildroot <buildroot@buildroot.org> wrote: > > [--SNIP--] > > > > The kconfig version dump itself: > > > > - support/kconfig: bump to linux-v6.9-rc5 version > > > So this commit without the next two leads to a broken situation, > > > correct? (Note: this is not a complaint, I agree with them being split). > > Except they should be reversed: the new commits can work with the > > kconfig we currently have, so it looks like it should be OK to do the > > required changes before doing the kconfig bump. > A solution for the two remaining patches working with the old/new kconfig would > be nice..., will test if it works for the escape problem... Right, making the env vars work in both caes would be quite difficult... However, the source-in-choice fix can very well be done before the kconfig bump. Regards, Yann E. MORIN.