[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2024032107-upstart-dragonfly-e346@gregkh>
Date: Thu, 21 Mar 2024 16:04:13 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev
Subject: Re: [GIT PULL] Char/Misc driver changes for 6.9-rc1
On Thu, Mar 21, 2024 at 06:48:31AM -0700, Nathan Chancellor wrote:
> On Thu, Mar 21, 2024 at 02:02:19PM +0100, Greg KH wrote:
> > All of these have been in linux-next for a long time with no reported
> > issue, other than a build warning with some older versions of gcc for a
> > speakup driver, fix for that will come in a few days when I catch up
> > with my pending patch queues.
> ...
> > Samuel Thibault (2):
> > speakup: Fix 8bit characters from direct synth
> > speakup: Add /dev/synthu device
>
> That build warning actually happens with clang, not GCC as far as I am
> aware, and it is actually a hard build error with older versions of
> clang, as Arnd points out in his patch to fix this (although the warning
> is a hard error with CONFIG_WERROR too, which causes allmodconfig to
> break):
>
> https://lore.kernel.org/20240313100413.875280-1-arnd@kernel.org/
>
> Samuel's patch was even simpler:
>
> https://lore.kernel.org/20240309203549.jj2l6epnznyjsrje@begin/
>
> Why was one of these changes not applied before this was sent? I am
> aware you were on vacation recently but you are now adding a known issue
> to -rc1, which can proliferate to other maintainer's trees and makes
> testing for us more difficult :/
You answered it yourself here, I'm supposed to still be on vacation and
this came in while I was supposed to be ignoring emails, AND it works
fine for me here, which is why I didn't queue it up to my tree for
inclusion in this pull request.
And sorry for the confusion with gcc/clang, I got that mixed up.
> -next has been broken for the entire
> merge window over this, which is usually when there is a chance we can
> get maybe a week of green builds...
Stuff will always slip up at times, given the low-stakes of this, I
didn't think it was needed right now, again, because my local testing
was just fine. I can go add it to the queue or if it affects Linus's
builds, he can take one of the above changes before I get a chance to
get through my todo mbox:
$ mdfrm -c ~/mail/todo/
1776 messages in /home/gregkh/mail/todo/
thanks,
greg "I need a vacation from my vacation..." k-h
Powered by blists - more mailing lists