All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: stable@vger.kernel.org
Subject: Re: Build failures in linux-4.9.y-stable-queue
Date: Fri, 15 Dec 2017 09:00:41 +0100	[thread overview]
Message-ID: <20171215080041.GA1031@kroah.com> (raw)
In-Reply-To: <20171215075338.GA25895@kroah.com>

On Fri, Dec 15, 2017 at 08:53:38AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Dec 15, 2017 at 08:46:13AM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Dec 15, 2017 at 08:43:32AM +0100, Greg Kroah-Hartman wrote:
> > > On Fri, Dec 15, 2017 at 08:42:25AM +0100, Greg Kroah-Hartman wrote:
> > > > On Thu, Dec 14, 2017 at 02:27:41PM -0800, Guenter Roeck wrote:
> > > > > Hi,
> > > > > 
> > > > > I thought the problem was fixed, but I still see:
> > > > > 
> > > > > arch/powerpc/include/asm/checksum.h:103:2: error:
> > > > > 	implicit declaration of function 'from64to32'
> > > > > 
> > > > > when building powerpc images (eg powerpc:defconfig).
> > > > > 
> > > > > This is with v4.9.69-20-g78542f2. v4.9.69 fails as well.
> > > > 
> > > > Yeah, I thought I took care of that already too.  I'm getting
> > > > conflicting reports from 0-day about this as well, it failed one build
> > > > cycle, then passed the next, and now failed again.  Ugh, let me try to
> > > > figure this out...
> > > 
> > > Ah, it passes powerpc builds on 0-day with the 'allnoconfig' build
> > > option, not with the defconfig, that explains that.
> > 
> > And the patch I tried to apply to fix this up didn't apply in the right
> > place, which is the problem here, let me go fix it now...
> > 
> > thanks for letting me know about this,
> 
> Ugh, this was bad.  Turns out that for the last release of 4.9 and 4.14,
> the last 5 or so patches never got applied when I created the git tree.
> They both stopped at the same place in the patch series, which is odd,
> but at least it means that they failed in the same way.

And now I know why.  They failed on the patch that modified the main
kernel Makefile, which makes sense as I hand-edit it to bump the version
number, so it was "dirty" and git would complain and stop applying
patches there.

I've "semi-scripted" the release process in the past few weeks, so an
error like this would not be caught, previously I would have noticed the
error as I applied the patches "by hand".  I'll go fix up my scripts to
not do this, and I'll go verify that I haven't dropped any other patches
like this recently either.

thanks,

greg k-h

      reply	other threads:[~2017-12-15  8:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-14 22:27 Build failures in linux-4.9.y-stable-queue Guenter Roeck
2017-12-15  7:42 ` Greg Kroah-Hartman
2017-12-15  7:43   ` Greg Kroah-Hartman
2017-12-15  7:46     ` Greg Kroah-Hartman
2017-12-15  7:53       ` Greg Kroah-Hartman
2017-12-15  8:00         ` Greg Kroah-Hartman [this message]

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=20171215080041.GA1031@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux@roeck-us.net \
    --cc=stable@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.