From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [autobuild.buildroot.net] Your build results for 2017-01-18
Date: Fri, 20 Jan 2017 13:18:17 +1100 [thread overview]
Message-ID: <20170120131817.382b2ac9@free-electrons.com> (raw)
In-Reply-To: <20170120003818.GA5114@tungsten.ozlabs.ibm.com>
Hello,
On Fri, 20 Jan 2017 11:38:18 +1100, Sam Bobroff wrote:
> > This is the list of Buildroot build failures that occured on
> > 2017-01-18, and for which you are a registered architecture developer
> > or package developer. Please help us improving the quality of
> > Buildroot by investigating those build failures and sending patches to
> > fix them. Thanks!
> >
> > Build failures related to your architectures:
>
> [snip]
>
> > powerpc64 | openocd-0.9.0 | http://autobuild.buildroot.net/results/0640114028b1e633cefc682e8d6a8283a3a39019
>
> Hi Thomas,
>
> I've had a look at the openocd failure, above, and while it's simple and
> I have a patch for it, there might be something odd going on so I
> thought I should ask you about it first.
>
> The failure is in the install stage, caused by the documentation being
> regenerated from the .texi input, which fails. It's easy to fix by
> tweaking the Makefile (actualy Makefile.in) as has been done on many
> other packages... however, what I'm curious about is why the error is
> showing up in the autobuilder in the first place.
>
> The file modification times in the package's archive seem to be correct:
> $ ls openocd-0.9.0.orig/doc/openocd.{info,texi}
> -rw-r--r-- 1 xxxx xxxx 3,542 2015-05-18 07:13:55.000000000 +1000
> openocd-0.9.0.orig/doc/openocd.info
> -rw-r--r-- 1 xxxx xxxx 354,589 2015-05-18 07:04:07.000000000 +1000
> openocd-0.9.0.orig/doc/openocd.texi
>
> (And I can't replicate the autobuilder failure unless I touch the .texi
> file.)
>
> Is something you've seen before? Could something on the autobuilder be
> touching a file or otherwise confusing the timestamp?
>
> What I don't understand is how this particular file causes a
> re-generation yet other files don't (e.g. Makefile.am would cause
> regeneration of Makefile.in but that doesn't happen).
>
> Any ideas? Just send the patch?
I don't really have a good idea. I'm adding the Buildroot mailing list
in Cc in case other folks have more ideas.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next parent reply other threads:[~2017-01-20 2:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170119072929.AFCF620C11@mail.free-electrons.com>
[not found] ` <20170120003818.GA5114@tungsten.ozlabs.ibm.com>
2017-01-20 2:18 ` Thomas Petazzoni [this message]
2017-02-02 21:19 ` [Buildroot] [autobuild.buildroot.net] Your build results for 2017-01-18 Arnout Vandecappelle
2017-02-02 23:06 ` Sam Bobroff
2017-02-02 23:27 ` Arnout Vandecappelle
2017-02-03 0:49 ` Sam Bobroff
2017-02-03 23:00 ` Arnout Vandecappelle
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=20170120131817.382b2ac9@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/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