* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-01-18
[not found] ` <20170120003818.GA5114@tungsten.ozlabs.ibm.com>
@ 2017-01-20 2:18 ` Thomas Petazzoni
2017-02-02 21:19 ` Arnout Vandecappelle
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2017-01-20 2:18 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-01-18
2017-01-20 2:18 ` [Buildroot] [autobuild.buildroot.net] Your build results for 2017-01-18 Thomas Petazzoni
@ 2017-02-02 21:19 ` Arnout Vandecappelle
2017-02-02 23:06 ` Sam Bobroff
0 siblings, 1 reply; 6+ messages in thread
From: Arnout Vandecappelle @ 2017-02-02 21:19 UTC (permalink / raw)
To: buildroot
On 20-01-17 03:18, Thomas Petazzoni wrote:
> 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.)
Weird that you can't reproduce. At the end of the build step I see:
Making all in doc
Updating ./version.texi
and of course version.texi is a dependency of openocd.info.
Regards,
Arnout
>>
>> 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
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-01-18
2017-02-02 21:19 ` Arnout Vandecappelle
@ 2017-02-02 23:06 ` Sam Bobroff
2017-02-02 23:27 ` Arnout Vandecappelle
0 siblings, 1 reply; 6+ messages in thread
From: Sam Bobroff @ 2017-02-02 23:06 UTC (permalink / raw)
To: buildroot
On Thu, Feb 02, 2017 at 10:19:08PM +0100, Arnout Vandecappelle wrote:
>
>
> On 20-01-17 03:18, Thomas Petazzoni wrote:
> > 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.)
>
> Weird that you can't reproduce. At the end of the build step I see:
>
> Making all in doc
> Updating ./version.texi
>
> and of course version.texi is a dependency of openocd.info.
Right, that's exactly what I'm talking about. It's clear to me that the
build will fail if it tries to rebuild the documentation, and I've got a
patch that can suppress it. *BUT* why is that rule being triggered on
the autobuilders? It's not triggered when I try to replicate it, and
that looks correct too, because:
$ tar tvf ~/dl/openocd-0.9.0.tar.bz2 |grep "doc/openocd"
-rw-r--r-- 1000/1000 300191 2015-05-18 07:13 openocd-0.9.0/doc/openocd.info-1
-rw-r--r-- 1000/1000 139898 2015-05-18 07:13 openocd-0.9.0/doc/openocd.info-2
-rw-r--r-- 1000/1000 3542 2015-05-18 07:13 openocd-0.9.0/doc/openocd.info
-rw-r--r-- 1000/1000 354589 2015-05-18 07:04 openocd-0.9.0/doc/openocd.texi
-rw-r--r-- 1000/1000 3237 2014-03-30 03:55 openocd-0.9.0/doc/openocd.1
... which clearly shows that the .info files are older than the .texi
file and no rebuild is necessary! (And as I would expect, I see these
timestamps unaltered in my build directory.) Could we hack some debug
into the autobuilder to show the file times before running the install
step? (pre-install hook perhaps?)
> Regards,
> Arnout
>
> >>
> >> 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
> >
>
> --
> Arnout Vandecappelle arnout at mind be
> Senior Embedded Software Architect +32-16-286500
> Essensium/Mind http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-01-18
2017-02-02 23:06 ` Sam Bobroff
@ 2017-02-02 23:27 ` Arnout Vandecappelle
2017-02-03 0:49 ` Sam Bobroff
0 siblings, 1 reply; 6+ messages in thread
From: Arnout Vandecappelle @ 2017-02-02 23:27 UTC (permalink / raw)
To: buildroot
On 03-02-17 00:06, Sam Bobroff wrote:
> On Thu, Feb 02, 2017 at 10:19:08PM +0100, Arnout Vandecappelle wrote:
>>
>>
>> On 20-01-17 03:18, Thomas Petazzoni wrote:
>>> 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.)
>>
>> Weird that you can't reproduce. At the end of the build step I see:
>>
>> Making all in doc
>> Updating ./version.texi
>>
>> and of course version.texi is a dependency of openocd.info.
>
> Right, that's exactly what I'm talking about. It's clear to me that the
> build will fail if it tries to rebuild the documentation, and I've got a
> patch that can suppress it. *BUT* why is that rule being triggered on
> the autobuilders? It's not triggered when I try to replicate it, and
> that looks correct too, because:
>
> $ tar tvf ~/dl/openocd-0.9.0.tar.bz2 |grep "doc/openocd"
> -rw-r--r-- 1000/1000 300191 2015-05-18 07:13 openocd-0.9.0/doc/openocd.info-1
> -rw-r--r-- 1000/1000 139898 2015-05-18 07:13 openocd-0.9.0/doc/openocd.info-2
> -rw-r--r-- 1000/1000 3542 2015-05-18 07:13 openocd-0.9.0/doc/openocd.info
> -rw-r--r-- 1000/1000 354589 2015-05-18 07:04 openocd-0.9.0/doc/openocd.texi
> -rw-r--r-- 1000/1000 3237 2014-03-30 03:55 openocd-0.9.0/doc/openocd.1
>
> ... which clearly shows that the .info files are older than the .texi
> file and no rebuild is necessary! (And as I would expect, I see these
> timestamps unaltered in my build directory.) Could we hack some debug
> into the autobuilder to show the file times before running the install
> step? (pre-install hook perhaps?)
The rule *is* triggered for me. Not in the build step, but in the install step.
Because at the end of the build step, version.texi is generated, and
openocd.info depends on version.texi (line 416 of Makefile.in).
So what is surprising is that it is not regenerated for you.
Regards,
Arnout
>
>> Regards,
>> Arnout
>>
>>>>
>>>> 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
>>>
>>
>> --
>> Arnout Vandecappelle arnout at mind be
>> Senior Embedded Software Architect +32-16-286500
>> Essensium/Mind http://www.mind.be
>> G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
>> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
>> GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-01-18
2017-02-02 23:27 ` Arnout Vandecappelle
@ 2017-02-03 0:49 ` Sam Bobroff
2017-02-03 23:00 ` Arnout Vandecappelle
0 siblings, 1 reply; 6+ messages in thread
From: Sam Bobroff @ 2017-02-03 0:49 UTC (permalink / raw)
To: buildroot
On Fri, Feb 03, 2017 at 12:27:11AM +0100, Arnout Vandecappelle wrote:
>
>
> On 03-02-17 00:06, Sam Bobroff wrote:
> > On Thu, Feb 02, 2017 at 10:19:08PM +0100, Arnout Vandecappelle wrote:
> >>
> >>
> >> On 20-01-17 03:18, Thomas Petazzoni wrote:
> >>> 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.)
> >>
> >> Weird that you can't reproduce. At the end of the build step I see:
> >>
> >> Making all in doc
> >> Updating ./version.texi
> >>
> >> and of course version.texi is a dependency of openocd.info.
> >
> > Right, that's exactly what I'm talking about. It's clear to me that the
> > build will fail if it tries to rebuild the documentation, and I've got a
> > patch that can suppress it. *BUT* why is that rule being triggered on
> > the autobuilders? It's not triggered when I try to replicate it, and
> > that looks correct too, because:
> >
> > $ tar tvf ~/dl/openocd-0.9.0.tar.bz2 |grep "doc/openocd"
> > -rw-r--r-- 1000/1000 300191 2015-05-18 07:13 openocd-0.9.0/doc/openocd.info-1
> > -rw-r--r-- 1000/1000 139898 2015-05-18 07:13 openocd-0.9.0/doc/openocd.info-2
> > -rw-r--r-- 1000/1000 3542 2015-05-18 07:13 openocd-0.9.0/doc/openocd.info
> > -rw-r--r-- 1000/1000 354589 2015-05-18 07:04 openocd-0.9.0/doc/openocd.texi
> > -rw-r--r-- 1000/1000 3237 2014-03-30 03:55 openocd-0.9.0/doc/openocd.1
> >
> > ... which clearly shows that the .info files are older than the .texi
> > file and no rebuild is necessary! (And as I would expect, I see these
> > timestamps unaltered in my build directory.) Could we hack some debug
> > into the autobuilder to show the file times before running the install
> > step? (pre-install hook perhaps?)
>
> The rule *is* triggered for me. Not in the build step, but in the install step.
> Because at the end of the build step, version.texi is generated, and
> openocd.info depends on version.texi (line 416 of Makefile.in).
>
> So what is surprising is that it is not regenerated for you.
Hmmm!
(The rule is triggered during the install step for me too.)
Yes, openocd.info depends on version.texi but on my system that doesn't
trigger a rebuild...
The core of it seems to be the rule in the doc/Makefile at
line 421, for handling $(srcdir)/stamp-vti (which is a dependency of
version.texi, which as you say, can trigger the re-generation of
openocd.info and the build failure).
On my system, this (seems to be) what happens when that rule runs:
* mdate-sh is used to generate a new version.texi
* that new version is compared to the existing one, they are the same
* version.texi is not copied
* no failure
You noted that that version.texi IS being re-generated when the build
fails so presumably mdate-sh is producing output that differs from
version.texi, causing the copy to happen and the build to fail. Or
something else is happening.
Since the build is failing for you, could you have a look at the build
directory after a failed build and post the content of doc/version.texi
as well as the modification time of doc/openocd.texi? Perhaps the file
is being touched somehow, or perhaps mdate-sh is generating subtly
different output for the same modification time (different end of line
or something?) and causing the compare to fail.
Thanks for the help!
Sam.
> Regards,
> Arnout
>
> >
> >> Regards,
> >> Arnout
> >>
> >>>>
> >>>> 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
> >>>
> >>
> >> --
> >> Arnout Vandecappelle arnout at mind be
> >> Senior Embedded Software Architect +32-16-286500
> >> Essensium/Mind http://www.mind.be
> >> G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
> >> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> >> GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
> >
>
> --
> Arnout Vandecappelle arnout at mind be
> Senior Embedded Software Architect +32-16-286500
> Essensium/Mind http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your build results for 2017-01-18
2017-02-03 0:49 ` Sam Bobroff
@ 2017-02-03 23:00 ` Arnout Vandecappelle
0 siblings, 0 replies; 6+ messages in thread
From: Arnout Vandecappelle @ 2017-02-03 23:00 UTC (permalink / raw)
To: buildroot
On 03-02-17 01:49, Sam Bobroff wrote:
> On Fri, Feb 03, 2017 at 12:27:11AM +0100, Arnout Vandecappelle wrote:
>>
>>
>> On 03-02-17 00:06, Sam Bobroff wrote:
>>> On Thu, Feb 02, 2017 at 10:19:08PM +0100, Arnout Vandecappelle wrote:
>>>>
>>>>
>>>> On 20-01-17 03:18, Thomas Petazzoni wrote:
>>>>> 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.)
>>>>
>>>> Weird that you can't reproduce. At the end of the build step I see:
>>>>
>>>> Making all in doc
>>>> Updating ./version.texi
>>>>
>>>> and of course version.texi is a dependency of openocd.info.
>>>
>>> Right, that's exactly what I'm talking about. It's clear to me that the
>>> build will fail if it tries to rebuild the documentation, and I've got a
>>> patch that can suppress it. *BUT* why is that rule being triggered on
>>> the autobuilders? It's not triggered when I try to replicate it, and
>>> that looks correct too, because:
>>>
>>> $ tar tvf ~/dl/openocd-0.9.0.tar.bz2 |grep "doc/openocd"
>>> -rw-r--r-- 1000/1000 300191 2015-05-18 07:13 openocd-0.9.0/doc/openocd.info-1
>>> -rw-r--r-- 1000/1000 139898 2015-05-18 07:13 openocd-0.9.0/doc/openocd.info-2
>>> -rw-r--r-- 1000/1000 3542 2015-05-18 07:13 openocd-0.9.0/doc/openocd.info
>>> -rw-r--r-- 1000/1000 354589 2015-05-18 07:04 openocd-0.9.0/doc/openocd.texi
>>> -rw-r--r-- 1000/1000 3237 2014-03-30 03:55 openocd-0.9.0/doc/openocd.1
>>>
>>> ... which clearly shows that the .info files are older than the .texi
>>> file and no rebuild is necessary! (And as I would expect, I see these
>>> timestamps unaltered in my build directory.) Could we hack some debug
>>> into the autobuilder to show the file times before running the install
>>> step? (pre-install hook perhaps?)
>>
>> The rule *is* triggered for me. Not in the build step, but in the install step.
>> Because at the end of the build step, version.texi is generated, and
>> openocd.info depends on version.texi (line 416 of Makefile.in).
>>
>> So what is surprising is that it is not regenerated for you.
>
> Hmmm!
>
> (The rule is triggered during the install step for me too.)
>
> Yes, openocd.info depends on version.texi but on my system that doesn't
> trigger a rebuild...
>
> The core of it seems to be the rule in the doc/Makefile at
> line 421, for handling $(srcdir)/stamp-vti (which is a dependency of
> version.texi, which as you say, can trigger the re-generation of
> openocd.info and the build failure).
>
> On my system, this (seems to be) what happens when that rule runs:
> * mdate-sh is used to generate a new version.texi
> * that new version is compared to the existing one, they are the same
> * version.texi is not copied
> * no failure
>
> You noted that that version.texi IS being re-generated when the build
> fails so presumably mdate-sh is producing output that differs from
> version.texi, causing the copy to happen and the build to fail. Or
> something else is happening.
Of course: timezone! mdate-sh gets the modtime of openocd.texi in localtime.
Since it was modified on 2015-05-17 21:04:07 UTC, in my timezone (CET) that is
still May 17. But the version.texi from the tarball has May 18... I guess it was
generated in some eastern timezone.
Still surprising that it works for you, since you seem to live in AEDT it
should also still be May 17 for you...
mdate-sh from automake-1.15 does export TZ=UTC. But of course adding that
wouldn't fix it here, because in UTC it is also still May 17...
Regards,
Arnout
>
> Since the build is failing for you, could you have a look at the build
> directory after a failed build and post the content of doc/version.texi
> as well as the modification time of doc/openocd.texi? Perhaps the file
> is being touched somehow, or perhaps mdate-sh is generating subtly
> different output for the same modification time (different end of line
> or something?) and causing the compare to fail.
>
> Thanks for the help!
> Sam.
>
>> Regards,
>> Arnout
>>
>>>
>>>> Regards,
>>>> Arnout
>>>>
>>>>>>
>>>>>> 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
>>>>>
>>>>
>>>> --
>>>> Arnout Vandecappelle arnout at mind be
>>>> Senior Embedded Software Architect +32-16-286500
>>>> Essensium/Mind http://www.mind.be
>>>> G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
>>>> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
>>>> GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
>>>
>>
>> --
>> Arnout Vandecappelle arnout at mind be
>> Senior Embedded Software Architect +32-16-286500
>> Essensium/Mind http://www.mind.be
>> G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
>> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
>> GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-02-03 23:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20170119072929.AFCF620C11@mail.free-electrons.com>
[not found] ` <20170120003818.GA5114@tungsten.ozlabs.ibm.com>
2017-01-20 2:18 ` [Buildroot] [autobuild.buildroot.net] Your build results for 2017-01-18 Thomas Petazzoni
2017-02-02 21:19 ` 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
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.