Miguel Ojeda wrote on Thu, Sep 20, 2018: > > I've not followed so closely, in particular I'm not sure if it's the > > only problem with arm32 right now, but that is a regression - the > > general serie is meant as an improvement, but these two patches fix > > 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually > > exclusive") which was taken in 4.19-rc1 > > > > (Miguel, perhaps a Fixes: tag might help remember that?) > > The commit is mentioned in the commit message, although not with the > Fixes: syntax -- is something now automatically parsing that? I guess > it is also easier for humans to parse :) As far as I'm aware, the backport to stable stuff parse these to know up till how far back they should backport, but it still requires explicit Cc to the stable@vger list... (not needed here as the "bad" commit never made it to stable) I'm not aware of anything else, but as you said, while I now see you naming the commit now, I managed to miss it earlier and I was somewhat following this so it's probably also easier on humans :) > > (If no-one in Cc has anything included in -next I could take them in my > > 9p branch, but that is quite a bit out of scope from what I advertised > > this branch as so I think it would be confusing ; I think it might > > almost be best if Miguel will keep maintaining these in the future to do > > his own request to inclusion in -next?) > > I can ask for my auxdisplay tree (or better, a new one) to be in -next > and use that (are non-kernel.org trees allowed to be in -next, by the > way?). I think a new one would be great, yes. (my branch is on github, so Stephen does not appear to mind non-kernel.org trees) -- Dominique Matinet