From: Thomas Backlund <tmb@mageia.org>
To: Masahiro Yamada <yamada.masahiro@socionext.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ulf Magnusson <ulfalizer@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: building in 32bit chroot on x86_64 host broken
Date: Thu, 7 Jun 2018 22:35:17 +0259 [thread overview]
Message-ID: <f1f35cdf-bd03-54bb-7196-c13131f7d0fc@mageia.org> (raw)
In-Reply-To: <CAK7LNAS4Xb_CQ31t_cqt3q0zRFZ-O2n3+qkxXfxZB_jmqvFmWQ@mail.gmail.com>
Den 2018-06-06 kl. 06:30, skrev Masahiro Yamada:
> Hi Linus,
>
> 2018-06-06 11:19 GMT+09:00 Linus Torvalds <torvalds@linux-foundation.org>:
>> On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>> But once you *have* that particular Kconfig, I do think that "make
>>> oldconfig" should just work. And it apparently used to.
>>>
>>> So I think this is a behavioral regression.
>> That doesn't necessarily mean that he fix should be to revert.
>
> If this is a regression, I am OK with the revert,
> and it is the only quick solution.
>
It is a regression as the same "make oldconfig routine" has been working
iirc since atleast 2.4 series kernels :)
But I dont see it as needing a "quick solution" revert if the "kconfig:
only write '# CONFIG_FOO is not set' for visible symbols" is considered
a "useful thing we want to keep"... I'd rather think waiting/working a
bit for a proper fix is the better way then...
I can work around it for now (or keep the revert in our kernel builds
for now) until it gets properly fixed...
Feel free to cc me on suggested fixes to test
--
Thomas
next prev parent reply other threads:[~2018-06-07 19:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-03 21:58 Linux 4.17 Linus Torvalds
2018-06-05 17:53 ` building in 32bit chroot on x86_64 host broken (was: Linux 4.17) Thomas Backlund
2018-06-05 18:11 ` Linus Torvalds
2018-06-05 18:24 ` building in 32bit chroot on x86_64 host broken Thomas Backlund
2018-06-05 18:38 ` Linus Torvalds
2018-06-05 18:51 ` Thomas Backlund
2018-06-05 19:13 ` Linus Torvalds
2018-06-05 19:36 ` Thomas Backlund
2018-06-06 1:37 ` Masahiro Yamada
2018-06-06 1:54 ` Linus Torvalds
2018-06-06 2:19 ` Linus Torvalds
2018-06-06 3:31 ` Masahiro Yamada
2018-06-07 19:36 ` Thomas Backlund [this message]
2018-06-07 19:40 ` Linus Torvalds
2018-06-07 19:49 ` Thomas Backlund
2018-06-09 12:16 ` Masahiro Yamada
2018-06-08 9:12 ` Michal Kubecek
2018-06-09 12:23 ` Masahiro Yamada
2018-06-09 16:49 ` Theodore Y. Ts'o
2018-06-05 18:12 ` building in 32bit chroot on x86_64 host broken - IGNORE Thomas Backlund
2018-06-05 20:10 ` python errors in tools/testing/selftests/tc-testing (was: Linux 4.17) Thomas Backlund
2018-06-05 21:01 ` python errors in tools/testing/selftests/tc-testing - IGNORE Thomas Backlund
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=f1f35cdf-bd03-54bb-7196-c13131f7d0fc@mageia.org \
--to=tmb@mageia.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=ulfalizer@gmail.com \
--cc=yamada.masahiro@socionext.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
all inboxes | Powered by JetHome®