hey guys, bigtop will only download it once! so the timestamp is of the download, a new download will never happen. you'll have to remove the jenkins job dir to force new downloads. insane == we have random gpdb versions in our CI depending on which phase of the moon the source for this combination of ci slave and OS the downloaded first.
olaf > Am 20.01.2017 um 05:25 schrieb Konstantin Boudnik <[email protected]>: > > According to > % gradlew gpdb-info > > Info for package gpdb > Will download from URL: > https://github.com/greenplum-db/gpdb/archive/master.zip > > which is exactly the archive of the current master branch. > > Cos > >> On Thu, Jan 19, 2017 at 10:10PM, MrAsanjar . wrote: >> it seems the gpdb source downloaded for the build is not from github >> master, check the config.guess timestamp msg: >> >> config.guess timestamp = 2011-05-11 >> >> uname -m = ppc64le >> uname -r = 4.4.0-34-generic >> uname -s = Linux >> uname -v = #53-Ubuntu SMP Wed Jul 27 16:04:07 UTC 2016 >> >> >> The new config.guess has the timestamp of timestamp='2017-01-01' >> https://github.com/greenplum-db/gpdb/blob/master/config/config.guess >> >> On Thu, Jan 19, 2017 at 4:28 PM, Roman Shaposhnik <[email protected]> >> wrote: >> >>> I see why its failing -- I just thought that's exactly what that patch >>> that went in was supposed to fix. >>> >>> Thanks, >>> Roman. >>> >>> On Thu, Jan 19, 2017 at 2:27 PM, Konstantin Boudnik <[email protected]> >>> wrote: >>>> On ppc64le it is failing because of this >>>> >>>> UNAME_VERSION = #53-Ubuntu SMP Wed Jul 27 16:04:07 UTC 2016 >>>> configure: error: cannot guess build type; you must specify one >>>> >>>> Cos >>>> >>>>> On Thu, Jan 19, 2017 at 02:22PM, Roman Shaposhnik wrote: >>>>>> On Thu, Jan 19, 2017 at 9:03 AM, Olaf Flebbe <[email protected]> wrote: >>>>>> hi amir >>>>>> >>>>>> the bigtop.bom for gpdb is plain insane: it fetches git trunk, rather >>> a defined piece of software. >>>>> >>>>> correct. but fwiw: since it does fetch trunk that patch should be in >>>>> there (since it was merged). >>>>> >>>>> this, in turn, makes me wonder why the heck the build is still red. >>>>> any thoughts? >>>>> >>>>>> we should change it to fetch the git merge point of that commit >>> instead or any later commit for now. >>>>>> i am very busy right now, anyone else can pick up that task. >>>>>> >>>>>> roman committed himself to update bigtop.bom when there is a >>> release;-/ >>>>> >>>>> still working on this -- but since it may not alight with the bigtop >>>>> release timeline we may >>>>> need to discuss other options (like not releasing it, etc.). >>>>> >>>>> Thanks, >>>>> Roman. >>>
