Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2021-09-25 Thread Timo Röhling 

Control: severity -1 wishlist

On Fri, 14 Oct 2016 14:03:48 -0400 Brad King  wrote:

FWIW I would not consider this test failure to be a blocking issue for
packaging a new CMake on this platform.  The behavior of this logic is
the same as it has been for years in CMake.  It is just that this test
case did not exist before.

Given this statement and the fact that the test failure seems to be
quite elusive and difficult to reproduce outside the buildd environment,
I ignored the failing tests for now.

I'll leave this bug open, as it is technically not fixed, but
drop the severity to wishlist.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-11-03 Thread Julian Andres Klode 
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 1.3~pre3 from two months
> > > ago, whereas the other platforms are at 1.3.1 already.
> 
> Steven Chamberlain wrote:
> > In the meantime, I believe I *could* build cmake on the porterboxes,
> > perhaps with DEB_BUILD_OPTS=nocheck and nmu those binaries.  It doesn't
> > fix the bug, would come back again with the next build, but it should
> > fix *many* reverse-deps that are FTBFS or BD-Uninstallable waiting for a
> > newer cmake.
> 
> I did that, but now apt FTBFS on kfreebsd-* with this test failure:
> 
> https://buildd.debian.org/status/fetch.php?pkg=apt=kfreebsd-amd64=1.3.1=1478121955
> 
> | [ RUN  ] FileUtlTest.GetTempDir
> | /«PKGBUILDDIR»/test/libapt/fileutl_test.cc:260: Failure
> | Value of: GetTempDir()
> |   Actual: "/tmp"
> | Expected: "/var/tmp"
> | [  FAILED  ] FileUtlTest.GetTempDir (0 ms)

Seems like /var/tmp is not rwx for the buildd user. It worked fine
on Linux and (real) FreeBSD last time I tried

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-11-03 Thread Steven Chamberlain 
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 1.3~pre3 from two months
> > ago, whereas the other platforms are at 1.3.1 already.

Steven Chamberlain wrote:
> In the meantime, I believe I *could* build cmake on the porterboxes,
> perhaps with DEB_BUILD_OPTS=nocheck and nmu those binaries.  It doesn't
> fix the bug, would come back again with the next build, but it should
> fix *many* reverse-deps that are FTBFS or BD-Uninstallable waiting for a
> newer cmake.

I did that, but now apt FTBFS on kfreebsd-* with this test failure:

https://buildd.debian.org/status/fetch.php?pkg=apt=kfreebsd-amd64=1.3.1=1478121955

| [ RUN  ] FileUtlTest.GetTempDir
| /«PKGBUILDDIR»/test/libapt/fileutl_test.cc:260: Failure
| Value of: GetTempDir()
|   Actual: "/tmp"
| Expected: "/var/tmp"
| [  FAILED  ] FileUtlTest.GetTempDir (0 ms)

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-10-28 Thread Samuel Thibault 
Control: retitle -1 cmake: FTBFS on kfreebsd: 2 tests fail: BuildDepends, 
RunCMake.Configure

Hello,

While fixing bug #840096 (timestamp issue in build of libxslt) for
hurd-i386, I happened to fix the issue for cmake too. Perhaps the same
may happen for kFreeBSD.

Samuel

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-10-14 Thread Brad King 
On 04/24/2016 11:59 AM, Andreas Beckmann wrote:
> On Thu, 7 Apr 2016 14:54:20 +0100 Steven Chamberlain wrote:
>> If I change all files except CustomCMakeInput.txt to have identical
>> timestamps, then I can reproduce the bug as seen on the buildds:
[snip]
>> And finally, it seems I can avoid that happening by making just the
>> Makefile have a newer timestamp than the others.  The bug is no longer
>> reproducible then:
[snip]
> You may have to consider make's behavior w.r.t. files of the identical
> time stamp:
[snip]
> A target is considered up-to-date if it's timestamp is newer *or same*
> as its prerequisites. Even if a prerequisite was just created.
> (#820658, this is documented make behavior)
> 
> And if I understand this correctly, cmake is doing the opposite:

That is *only* in the if(IS_NEWER_THAN) check which does not come into
play in the RunCMake.Configure test AFAIK.  The way CMake decides whether
it needs to re-configure is the following:

* The "make" tool sees the cmake_check_build_system target in the Makefile
  as always out of date and always runs CMake to do the check.  See
  the `cmake::CheckBuildSystem` method for the implementation.

* CMake reads CMakeFiles/Makefile.cmake and collects the timestamps
  of all the files listed as CMAKE_MAKEFILE_{DEPENDS,OUTPUTS}.

* CMake finds the newest entry in DEPENDS and the oldest entry in OUTPUTS.

* If the newest dependency is newer than (but not equal to) the oldest
  output then it decides to re-run.  This is the same as the "make"
  behavior for identical timestamps.

If you place `VERBOSE=1` in your environment then CMake will print out
what pair of files caused it to decide to re-run.

Steven, in your earlier test that I quoted above, did you ensure that
the timestamps of all files listed as described above (which includes
some under CMakeFiles/) had the same timestamp?  If not then I don't
think the test was set up the way you intended.

-

FWIW I would not consider this test failure to be a blocking issue for
packaging a new CMake on this platform.  The behavior of this logic is
the same as it has been for years in CMake.  It is just that this test
case did not exist before.

-Brad

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-10-10 Thread Steven Chamberlain 
Hi!

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 1.3~pre3 from two months
> ago, whereas the other platforms are at 1.3.1 already.

There is an interesting bug here but I could not figure it out myself,
and upstream couldn't reproduce it in their own build/test environments
(which includes Mac OS but not actually kfreebsd or hurd).

In the meantime, I believe I *could* build cmake on the porterboxes,
perhaps with DEB_BUILD_OPTS=nocheck and nmu those binaries.  It doesn't
fix the bug, would come back again with the next build, but it should
fix *many* reverse-deps that are FTBFS or BD-Uninstallable waiting for a
newer cmake.

Since kfreebsd is anyway not a release architecture for stretch I don't
see a strong argument against doing this?  (hurd has already done this).

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-10-10 Thread Julian Andres Klode 
Control: affects -1 apt
Control: subscribe -1

On Sat, Feb 20, 2016 at 12:00:51PM +0100, Andreas Beckmann wrote:
> Package: cmake
> Version: 3.4.1-2
> Severity: important
> 
> Hi,
> 
> cmake FTBFS on kfreebsd-* and hurd-i386:
> 
> https://buildd.debian.org/status/fetch.php?pkg=cmake=hurd-i386=3.4.1-2=1450146549
> https://buildd.debian.org/status/fetch.php?pkg=cmake=kfreebsd-amd64=3.4.1-2=1451070849
> https://buildd.debian.org/status/fetch.php?pkg=cmake=kfreebsd-i386=3.4.1-2=1451071199
> 
> 99% tests passed, 2 tests failed out of 413
> 
> Label Time Summary:
> Label1=   0.58 sec (1 test)
> Label2=   0.58 sec (1 test)
> 
> Total Test time (real) = 4164.45 sec
> 
> The following tests FAILED:
>   113 - BuildDepends (Failed)
>   292 - RunCMake.Configure (Failed)
> Makefile:152: recipe for target 'test' failed

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 1.3~pre3 from two months
ago, whereas the other platforms are at 1.3.1 already.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-24 Thread Andreas Beckmann 
On Thu, 7 Apr 2016 14:54:20 +0100 Steven Chamberlain
 wrote:
> If I change all files except CustomCMakeInput.txt to have identical
> timestamps, then I can reproduce the bug as seen on the buildds:
> 
> -rw-r--r-- 1 pbuilder1 build 1420 2016-04-07 13:46:31.600236000 + 
> cmake_install.cmake
> -rw-r--r-- 1 pbuilder1 build 3940 2016-04-07 13:46:31.600236000 + Makefile
> -rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:31.600236000 + 
> CustomCMakeStamp.txt
> -rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:31.600236000 + 
> CustomCMakeOutput.txt
> -rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:31.600236000 + 
> CustomCMakeDepend.txt
> drwxr-xr-x 3 pbuilder1 build   10 2016-04-07 13:46:31.600236000 + 
> CMakeFiles
> -rw-r--r-- 1 pbuilder1 build 4308 2016-04-07 13:46:31.600236000 + 
> CMakeCache.txt
> drwxr-xr-x 6 pbuilder1 build6 2016-04-07 13:46:31.600236252 + ..
> drwxr-xr-x 3 pbuilder1 build   10 2016-04-07 13:46:32.653236466 + .
> -rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:32.673236479 + 
> CustomCMakeInput.txt
> 
> leads to:
>   Expected stamp '1' but got: '2'
> 
> And finally, it seems I can avoid that happening by making just the
> Makefile have a newer timestamp than the others.  The bug is no longer
> reproducible then:

You may have to consider make's behavior w.r.t. files of the identical
time stamp:

===
all: race

foo:
echo foo > $@

foobar: foo
cat $< > $@

test: foobar
grep foo $<

clean:
$(RM) foo foobar

norace: clean
$(MAKE) test

race: clean
echo barf > foobar
$(MAKE) test

race2: clean
echo barf > foobar
sleep 0.5
$(MAKE) test

race3: clean
echo barf > foobar
sleep 0.99
$(MAKE) test
===

This frequently fails even on high-resolution file systems.

A target is considered up-to-date if it's timestamp is newer *or same*
as its prerequisites. Even if a prerequisite was just created.
(#820658, this is documented make behavior)

And if I understand this correctly, cmake is doing the opposite:

On Thu, 7 Apr 2016 08:43:08 -0400 Brad King  wrote:
> FYI, the IS_NEWER_THAN check actually documents that it returns true
> when the times are exactly equal:
>
>   https://cmake.org/cmake/help/v3.5/command/if.html
>   "If the file time stamps are exactly the same, an IS_NEWER_THAN
>   comparison returns true, so that any dependent build operations
>   will occur in the event of a tie."

So good luck if both cmake and make get involved in such a race.


Andreas

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-11 Thread Steven Chamberlain 
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 is how I'm invoking the test on its own (10 times) :

$ m=0 ; n=0 ; for i in $(seq 1 10) ; do Build/bin/cmake 
"-DCMAKE_MODULE_PATH=Tests/RunCMake" "-DRunCMake_GENERATOR=Unix Makefiles" 
"-DRunCMake_GENERATOR_PLATFORM=" "-DRunCMake_GENERATOR_TOOLSET=" 
"-DRunCMake_MAKE_PROGRAM=/usr/bin/make" 
"-DRunCMake_SOURCE_DIR=$(pwd)/Tests/RunCMake/Configure" 
"-DRunCMake_BINARY_DIR=$(pwd)/Build/Tests/RunCMake/Configure" "-P" 
"Tests/RunCMake/Configure/RunCMakeTest.cmake" && m=$((m+1)) ; n=$((n+1)) ; echo 
"PASSED $m/$n of iterations" ; done 2>&1 | tee test.log

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
--- a/Tests/RunCMake/Configure/RunCMakeTest.cmake
+++ b/Tests/RunCMake/Configure/RunCMakeTest.cmake
@@ -16,9 +16,10 @@
 file(WRITE "${input}" "1")
 file(WRITE "${depend}" "1")
 run_cmake(RerunCMake)
-execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution
 file(WRITE "${input}" "2")
+execute_process(COMMAND ${CMAKE_COMMAND} -E env bash -c "ls -altr --full-time ${RunCMake_TEST_BINARY_DIR}")
 run_cmake_command(RerunCMake-build1 ${CMAKE_COMMAND} --build .)
+execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution
 file(WRITE "${depend}" "2")
 run_cmake_command(RerunCMake-build2 ${CMAKE_COMMAND} --build .)
 unset(RunCMake_TEST_BINARY_DIR)


signature.asc
Description: Digital signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-07 Thread Steven Chamberlain 
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:
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileTimeComparison.cxx;hb=v3.5.1#l151

I should try to find a smaller testcase to confirm this.  I'll need
to set up a UFS partition on a development machine so I can test
properly.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-07 Thread Steven Chamberlain 
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")`, normally:

-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:48:45.070227065 + 
CustomCMakeDepend.txt
drwxr-xr-x 6 pbuilder1 build6 2016-04-07 13:48:45.070227065 + ..
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:48:45.086227203 + 
CustomCMakeStamp.txt
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:48:45.087227201 + 
CustomCMakeOutput.txt
-rw-r--r-- 1 pbuilder1 build 4308 2016-04-07 13:48:45.125227266 + 
CMakeCache.txt
-rw-r--r-- 1 pbuilder1 build 1420 2016-04-07 13:48:45.126227116 + 
cmake_install.cmake
-rw-r--r-- 1 pbuilder1 build 3940 2016-04-07 13:48:45.126227116 + Makefile
drwxr-xr-x 3 pbuilder1 build   10 2016-04-07 13:48:45.127227322 + CMakeFiles
drwxr-xr-x 3 pbuilder1 build   10 2016-04-07 13:48:45.127227322 + .
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:48:45.128227034 + 
CustomCMakeInput.txt

If I change all files except CustomCMakeInput.txt to have identical
timestamps, then I can reproduce the bug as seen on the buildds:

-rw-r--r-- 1 pbuilder1 build 1420 2016-04-07 13:46:31.600236000 + 
cmake_install.cmake
-rw-r--r-- 1 pbuilder1 build 3940 2016-04-07 13:46:31.600236000 + Makefile
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:31.600236000 + 
CustomCMakeStamp.txt
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:31.600236000 + 
CustomCMakeOutput.txt
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:31.600236000 + 
CustomCMakeDepend.txt
drwxr-xr-x 3 pbuilder1 build   10 2016-04-07 13:46:31.600236000 + CMakeFiles
-rw-r--r-- 1 pbuilder1 build 4308 2016-04-07 13:46:31.600236000 + 
CMakeCache.txt
drwxr-xr-x 6 pbuilder1 build6 2016-04-07 13:46:31.600236252 + ..
drwxr-xr-x 3 pbuilder1 build   10 2016-04-07 13:46:32.653236466 + .
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:32.673236479 + 
CustomCMakeInput.txt

leads to:
  Expected stamp '1' but got: '2'

And finally, it seems I can avoid that happening by making just the
Makefile have a newer timestamp than the others.  The bug is no longer
reproducible then:

-rw-r--r-- 1 pbuilder1 build 1420 2016-04-07 13:46:51.367235000 + 
cmake_install.cmake
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:51.367235000 + 
CustomCMakeStamp.txt
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:51.367235000 + 
CustomCMakeOutput.txt
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:51.367235000 + 
CustomCMakeDepend.txt
drwxr-xr-x 3 pbuilder1 build   10 2016-04-07 13:46:51.367235000 + CMakeFiles
-rw-r--r-- 1 pbuilder1 build 4308 2016-04-07 13:46:51.367235000 + 
CMakeCache.txt
drwxr-xr-x 6 pbuilder1 build6 2016-04-07 13:46:51.367235044 + ..
-rw-r--r-- 1 pbuilder1 build 3940 2016-04-07 13:46:52.0 + Makefile
drwxr-xr-x 3 pbuilder1 build   10 2016-04-07 13:46:52.437235005 + .
-rw-r--r-- 1 pbuilder1 build1 2016-04-07 13:46:52.466234887 + 
CustomCMakeInput.txt

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-07 Thread Brad King 
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 likely fail on those filesystems.
> 
> I think the testcase should allow something like "newer or equal to".
> I don't know if there's a CMake macro to do exactly that.

FYI, the IS_NEWER_THAN check actually documents that it returns true
when the times are exactly equal:

  https://cmake.org/cmake/help/v3.5/command/if.html
  "If the file time stamps are exactly the same, an IS_NEWER_THAN
  comparison returns true, so that any dependent build operations
  will occur in the event of a tie."

One can confirm this in the implementation here:

  
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmConditionEvaluator.cxx;hb=v3.5.1#l720
  "fileIsNewer==1 || fileIsNewer==0"

This change was made to CMake long ago specifically to fix cases on
filesystems with low time resolution.  Upstream CMake nightly testing
runs on some filesystems with 1s resolution, such as HFS on OS X.

The failures under discussion here are indeed strange.  Thanks for
investigating!

-Brad

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-07 Thread Steven Chamberlain 
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
+++ b/Tests/RunCMake/Configure/RunCMakeTest.cmake
@@ -15,6 +15,7 @@
 set(output "${RunCMake_TEST_BINARY_DIR}/CustomCMakeOutput.txt")
 file(WRITE "${input}" "1")
 file(WRITE "${depend}" "1")
+execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution
 run_cmake(RerunCMake)
 execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution
 file(WRITE "${input}" "2")
--- a/Tests/RunCMake/Configure/RerunCMake.cmake
+++ b/Tests/RunCMake/Configure/RerunCMake.cmake
@@ -9,3 +9,5 @@
 file(READ ${depend} content)
 file(WRITE ${output} "${content}")
 set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS RerunCMake.txt)
+
+execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution


signature.asc
Description: Digital signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-07 Thread Samuel Thibault 
Steven Chamberlain, on Thu 07 Apr 2016 11:54:26 +0100, wrote:
> Samuel Thibault wrote:
> > Nothing was attached :)
> 
> Sorry - attached!

Mmm, nope :)

Samuel

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-07 Thread Samuel Thibault 
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 :)

Samuel

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-07 Thread Steven Chamberlain 
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 CustomCMakeDepend.txt

The sleep in Tests/RunCMake/Configure/RerunCMake.cmake is intended to
make CMakeCache.txt newer than ConfigureFileOutput.txt

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-07 Thread Samuel Thibault 
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 you try
> the attached instead?

Nothing was attached :)

Samuel

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-06 Thread Steven Chamberlain 
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 
> ...***Failed3.19 sec

I have a wild idea what might be happening here.  Please could you try
the attached instead?  You don't need to recompile the whole thing but
only run the single test again with this change, if you still have the
build tree around.

The test was designed to detect cases of CMake running 'again'
unexpectedly, after the explicit run_cmake(RerunCMake).

After writing a new value "2" to CustomCMakeInput.txt, which is not a
declared dependency, it is expected that CMake will not run again and
copy it to the output file (CustomCMakeStamp.txt).

My guess is... if the declared dependency (CustomCMakeDepend.txt) and
output (CustomCMakeOutput.txt) have exactly the same timestamp, it
doesn't know for sure that the output is up-to-date, so it errs on the
side of running again, triggering the bug.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-06 Thread Christoph Egger 
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 the attached patch please?

Start 284: RunCMake.Configure
284/371 Test #284: RunCMake.Configure ...***Failed  
  3.19 sec

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-06 Thread Christoph Egger 
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:
>
> $ Build/bin/cmake "-DCMAKE_MODULE_PATH=Tests/RunCMake"
> "-DRunCMake_GENERATOR=Unix Makefiles" "-DRunCMake_GENERATOR_PLATFORM="
> "-DRunCMake_GENERATOR_TOOLSET="
> "-DRunCMake_MAKE_PROGRAM=/usr/bin/make"
> "-DRunCMake_SOURCE_DIR=$(pwd)/Tests/RunCMake/Configure"
> "-DRunCMake_BINARY_DIR=$(pwd)/Build/Tests/RunCMake/Configure" "-P"
> "Tests/RunCMake/Configure/RunCMakeTest.cmake"

I have the build running on falla currently and it's already in the
testsuite so I'll just wait for it to finish

  Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer


signature.asc
Description: PGP signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-06 Thread Steven Chamberlain 
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" 
"-DRunCMake_GENERATOR=Unix Makefiles" "-DRunCMake_GENERATOR_PLATFORM=" 
"-DRunCMake_GENERATOR_TOOLSET=" "-DRunCMake_MAKE_PROGRAM=/usr/bin/make" 
"-DRunCMake_SOURCE_DIR=$(pwd)/Tests/RunCMake/Configure" 
"-DRunCMake_BINARY_DIR=$(pwd)/Build/Tests/RunCMake/Configure" "-P" 
"Tests/RunCMake/Configure/RunCMakeTest.cmake"

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-06 Thread Steven Chamberlain 
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
+++ b/Tests/RunCMake/Configure/RunCMakeTest.cmake
@@ -16,7 +16,7 @@
 file(WRITE "${input}" "1")
 file(WRITE "${depend}" "1")
 run_cmake(RerunCMake)
-execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 1) # handle 1s resolution
+execute_process(COMMAND ${CMAKE_COMMAND} -E sleep 2) # handle 1s resolution
 file(WRITE "${input}" "2")
 run_cmake_command(RerunCMake-build1 ${CMAKE_COMMAND} --build .)
 file(WRITE "${depend}" "2")


signature.asc
Description: Digital signature

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-04-06 Thread Steven Chamberlain 
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 buildds have, and also maybe some
Linux fileystems too.

| if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
|   if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt
|   IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt)
| message(STATUS "multi2-real.txt is newer than multi2-stamp.txt")
|   else()
| message(SEND_ERROR "Project did not initially build properly: "
|   "multi2-real.txt is not newer than multi2-stamp.txt")

If multi2-real.txt and multi2-stamp.txt are created within 1 second of
each other, the test will most likely fail on those filesystems.

I think the testcase should allow something like "newer or equal to".
I don't know if there's a CMake macro to do exactly that.

By reversing the operands and the logic, it is possible to test for
"multi2-stamp.txt newer than multi2-real.txt" as a failure condition,
and therefore "multi2-real.txt newer or equal to multi2-stamp.txt" will
be regarded a success, which is exactly what we want here.

A patch is attached.  I can't test it fully, because my kfreebsd systems
are not affected by this bug:  they use ZFS, which does have sub-second
file timestamps.  At least with this patch applied I didn't see any
regression, and on UFS... I feel lucky that this will fix it.


>   292 - RunCMake.Configure (Failed)

I didn't look at that other test failure yet...

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
Date: Wed, 06 Apr 2016 22:28:55 +0100
From: Steven Chamberlain 
Subject: Tests: allow newer or equal timestamps in BuildDepends

Allow timestamps to be newer *or equal* in BuildDepends, in case the
filesystem lacks sub-second granularity (such as UFS on FreeBSD).

The test logic is changed from A > B, to !(B > A), i.e. A >= B

--- a/Tests/BuildDepends/CMakeLists.txt
+++ b/Tests/BuildDepends/CMakeLists.txt
@@ -202,12 +202,12 @@
 endif()
 
 if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
-  if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt
-  IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt)
-message(STATUS "multi2-real.txt is newer than multi2-stamp.txt")
-  else()
+  if(${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt
+  IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
 message(SEND_ERROR "Project did not initially build properly: "
-  "multi2-real.txt is not newer than multi2-stamp.txt")
+  "multi2-real.txt timestamp is not >= multi2-stamp.txt")
+  else()
+message(STATUS "multi2-real.txt timestamp is >= multi2-stamp.txt")
   endif()
 else()
   message(SEND_ERROR "Project did not initially build properly: "
@@ -216,12 +216,12 @@
 
 if(TEST_MULTI3)
   if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi3-real.txt)
-if(${BuildDepends_BINARY_DIR}/Project/multi3-real.txt
-IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi3-stamp.txt)
-  message(STATUS "multi3-real.txt is newer than multi3-stamp.txt")
-else()
+if(${BuildDepends_BINARY_DIR}/Project/multi3-stamp.txt
+IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi3-real.txt)
   message(SEND_ERROR "Project did not initially build properly: "
-"multi3-real.txt is not newer than multi3-stamp.txt")
+"multi3-real.txt timestamp is not >= multi3-stamp.txt")
+else()
+  message(STATUS "multi3-real.txt timestamp is >= multi3-stamp.txt")
 endif()
   else()
 message(SEND_ERROR "Project did not initially build properly: "
@@ -405,12 +405,12 @@
 endif()
 
 if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
-  if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt
-  IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt)
-message(STATUS "multi2-real.txt is newer than multi2-stamp.txt")
-  else()
+  if(${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt
+  IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-real.txt)
 message(SEND_ERROR "Project did not rebuild properly: "
-  "multi2-real.txt is not newer than multi2-stamp.txt")
+  "multi2-real.txt timestamp is not >= multi2-stamp.txt")
+  else()
+message(STATUS "multi2-real.txt is >= multi2-stamp.txt")
   endif()
 else()
   message(SEND_ERROR "Project did not rebuild properly: "
@@ -419,12 +419,12 @@
 
 if(TEST_MULTI3)
   if(EXISTS ${BuildDepends_BINARY_DIR}/Project/multi3-real.txt)
-if(${BuildDepends_BINARY_DIR}/Project/multi3-real.txt
-IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi3-stamp.txt)
-  message(STATUS "multi3-real.txt is newer than multi3-stamp.txt")
-else()
+if(${BuildDepends_BINARY_DIR}/Project/multi3-stamp.txt
+IS_NEWER_THAN

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

2016-02-20 Thread Andreas Beckmann 
Package: cmake
Version: 3.4.1-2
Severity: important

Hi,

cmake FTBFS on kfreebsd-* and hurd-i386:

https://buildd.debian.org/status/fetch.php?pkg=cmake=hurd-i386=3.4.1-2=1450146549
https://buildd.debian.org/status/fetch.php?pkg=cmake=kfreebsd-amd64=3.4.1-2=1451070849
https://buildd.debian.org/status/fetch.php?pkg=cmake=kfreebsd-i386=3.4.1-2=1451071199

99% tests passed, 2 tests failed out of 413

Label Time Summary:
Label1=   0.58 sec (1 test)
Label2=   0.58 sec (1 test)

Total Test time (real) = 4164.45 sec

The following tests FAILED:
113 - BuildDepends (Failed)
292 - RunCMake.Configure (Failed)
Makefile:152: recipe for target 'test' failed


Andreas