* [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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox