Re: /tmp/cctnQ1CM.s:35: Error: .err encountered

[Dmitry Vyukov]

On Sat, Jun 30, 2018 at 8:07 PM, Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sat, 30 Jun 2018 12:27:09 +0200 Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
>
>> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> > head:   1904148a361a07fb2d7cba1261d1d2c2f33c8d2e
>> > commit: 758517202bd2e427664857c9f2aa59da36848aca arm: port KCOV to arm
>> > date:   2 weeks ago
>> > config: arm-allmodconfig (attached as .config)
>> > compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
>> > reproduce:
>> >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>> >         chmod +x ~/bin/make.cross
>> >         git checkout 758517202bd2e427664857c9f2aa59da36848aca
>> >         # save the attached .config to linux build tree
>> >         GCC_VERSION=7.2.0 make.cross ARCH=arm
>> >
>> > All errors (new ones prefixed by >>):
>> >
>> >    /tmp/cctnQ1CM.s: Assembler messages:
>> >>> /tmp/cctnQ1CM.s:35: Error: .err encountered
>> >    /tmp/cctnQ1CM.s:36: Error: .err encountered
>> >    /tmp/cctnQ1CM.s:37: Error: .err encountered
>>
>> Hi kbuild test robot,
>>
>> The fix was mailed more than a month ago, but still not merged into
>> the tree. That's linux...
>
> That was a rather unhelpful email.
>
> I've just scanned all your lkml emails since the start of May and
> cannot find anything which looks like a fix for this issue.
>
> Please resend.   About three weks ago :(


Sorry. I am just frustrated by kernel development process.

Bugs are untracked and get lost. Patches are untracked and get lost.
State of patches is nontransparent for most people, including author
(sic!). I've just got a reply on another patch along the lines of "oh,
I've already merged some unspecified version of this patch, so please
resent all changes since that unspecified version in a separate patch"
(what?). It's unclear what is the designated tree and who is the
designated responsible merger. Merging a build fixing patch takes
months (!) whereas most other modern project processes today are
capable of merging such changes into (the single head) tree within an
hour provided only a single maintainer from a group is around, and
they simply need to click a button because all tests, style and
mergability checks have already run by that time. Resending patches
thing should not exist unless the patch needs to be updated, condition
which is detectable automatically.

Andrew, none of this is related to you personally. That's the process
we have today, and I understand you are doing your best.