On Thu, Nov 03, 2016 at 04:57:00PM +, Steven Chamberlain wrote:
> Hello,
>
> > Julian Andres Klode wrote:
> > > Any update on this? This bug is preventing the kFreeBSD platforms
> > > from getting a newer APT version, as APT requires cmake (>= 3.4)
> > > to build. Because of this, APT is at
Hi,
I set up a UFS filesystem to build on, but could not reproduce the bug.
Please could someone try the attached diff? If it fails, please share
the exact error (does it fail at the -build1 step or at -build2?), and
because the `ls` I added will show the file timestamps, to help debug.
This
Brad King wrote:
> FYI, the IS_NEWER_THAN check actually documents that it returns true
> when the times are exactly equal:
Thanks for pointing that out!
I suppose it is not working as expected, then, but I can't see why.
kfreebsd does have st_mtim, and the code for that looks right to me:
Hi,
I've tried looking at this from the other direction -- on ZFS
with high-resolution timestamps, I'm trying to find a way to reproduce
the issue as seen on the Debian buildds.
Here are timestamps in Build/Tests/RunCMake/Configure/RerunCMake-build/
right after `file(WRITE "${input}" "2")`,
On 04/06/2016 05:42 PM, Steven Chamberlain wrote:
> | if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt
> | IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt)
>
> If multi2-real.txt and multi2-stamp.txt are created within 1 second of
> each other, the test will most
Samuel Thibault wrote:
> BTW, you may find
> set abort_noattach=ask-yes
>
> useful in .muttrc :)
Thanks! I will try that. And maybe more sleep, or coffee.
Patch might be attached.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/Tests/RunCMake/Configure/RunCMakeTest.cmake
+++
Samuel Thibault, on Thu 07 Apr 2016 13:07:18 +0200, wrote:
> Steven Chamberlain, on Thu 07 Apr 2016 11:54:26 +0100, wrote:
> > Samuel Thibault wrote:
> > > Nothing was attached :)
> >
> > Sorry - attached!
>
> Mmm, nope :)
BTW, you may find
set abort_noattach=ask-yes
useful in .muttrc :)
Steven Chamberlain, on Thu 07 Apr 2016 11:54:26 +0100, wrote:
> Samuel Thibault wrote:
> > Nothing was attached :)
>
> Sorry - attached!
Mmm, nope :)
Samuel
Samuel Thibault wrote:
> Nothing was attached :)
Sorry - attached!
Christoph found that increasing some of these sleeps to 3 seconds
allowed the test to pass *some* of the time.
The first sleep in Tests/RunCMake/Configure/RunCMakeTest.cmake should
make CustomCMakeOutput.txt newer than
Steven Chamberlain, on Thu 07 Apr 2016 01:47:58 +0100, wrote:
> Christoph Egger wrote:
> > Start 284: RunCMake.Configure
> > 284/371 Test #284: RunCMake.Configure
> > ...***Failed3.19 sec
>
> I have a wild idea what might be happening here. Please could
Hi,
> Steven Chamberlain writes:
> > Could someone with access to the hurd-i386 or kfreebsd porter boxes
> > try the attached patch please?
Christoph Egger wrote:
> Start 284: RunCMake.Configure
> 284/371 Test #284: RunCMake.Configure
>
Steven Chamberlain writes:
> Steven Chamberlain wrote:
>> Could someone with access to the hurd-i386 or kfreebsd porter boxes
>> try the attached patch please?
>
> Here's how to run that test on its own, verbosely, in an already-built
> Debian build tree:
>
> $
Hi
FWIW on the 3.2 build (with the patch) I started untill I noticed it
wasn't quite the right version
Steven Chamberlain writes:
> Andreas Beckmann wrote:
>> 292 - RunCMake.Configure (Failed)
>
> Could someone with access to the hurd-i386 or kfreebsd porter boxes
> try
Steven Chamberlain wrote:
> Could someone with access to the hurd-i386 or kfreebsd porter boxes
> try the attached patch please?
Here's how to run that test on its own, verbosely, in an already-built
Debian build tree:
$ Build/bin/cmake "-DCMAKE_MODULE_PATH=Tests/RunCMake"
Hi,
Andreas Beckmann wrote:
> 292 - RunCMake.Configure (Failed)
Could someone with access to the hurd-i386 or kfreebsd porter boxes
try the attached patch please?
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/Tests/RunCMake/Configure/RunCMakeTest.cmake
+++
Hi,
Andreas Beckmann wrote:
> The following tests FAILED:
> 113 - BuildDepends (Failed)
I finally figured this out!
The BuildDepends test will fail when run on a filesystem not having
sub-second granularity. So for example, it fails on kfreebsd UFS, and
whatever filesystem the hurd-i386
16 matches
Mail list logo