status of release 1.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

status of release 1.1

Markus Wanner-2
Hi,

we're mostly ready for a 1.1 release. I fixed the intermittent issues in
the extra tests. The revived build farm looks reasonably green, now.

At the moment, the head of net.venge.monotone is known (to me) to
compile fine and pass all tests on the following platforms:

  Debian, testing & sid, Linux & kFreeBSD, i386 & amd64 & armel,
    using g++ as well as clang++
  Ubuntu precise
  Gentoo (amd64, hardened)
  NetBSD 6
  CentOS 6.5
  Cygwin 64-bit
  OmniOS r151008

MinGW (32-bit) fails on the extra tests (see build animal "boar"), but I
don't think that's release critical.

What's clearly missing is MacOS X. So if you have access to a box with
that OS, please give it a spin (and consider providing a buildbot slave,
please).

I hope to bundle the release within the next few days.

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Thomas Keller

Hi Markus!

Markus Wanner schrieb:
> Hi,
>
> we're mostly ready for a 1.1 release. I fixed the intermittent issues in
> the extra tests. The revived build farm looks reasonably green, now.

Thanks for the effort!

> What's clearly missing is MacOS X. So if you have access to a box with
> that OS, please give it a spin (and consider providing a buildbot slave,
> please).

I'm on 10.9 (Mavericks) here. I had no recent enough mtn installation
around, so I had to copy sources and build from there.

Things that I've stumbled upon  so far:

* Don't use gcc from MacPorts to build, it will bring up weird linker
  errors (see my previous post from February), but stick to plain clang
  (which Apple advertises as gcc and g++ in the /usr/bin prefix)

* Mix-in libidn, liblua, libbotan, libpcre and else from MacPorts via
  CXXFLAGS="-I/opt/local/include" LDFLAGS="-L/opt/local/lib" (where
  /opt/local is the MacPorts prefix)

* Monotone has no support for botan's "special" versioned package-
  config file that botan seems to use since 1.10, so some more flag
  magic was needed, namely
  botan_CFLAGS="-I/opt/local/include/botan-1.10"
  botan_LIBS="-lbotan-1.10"

* If gettext is not available, make (not make dist) fails with a
  cryptic

  make[2]: Circular po/sv.gmo <- po/sv.gmo dependency dropped.

  I guess this is because of Makefile.am's

  po/%.gmo: $(srcdir)/po/%.gmo
        cp $< $@

  which looks a bit fishy indeed.

  When gettext is installed, this does not pop up, of course.

* make install failed for me, because mtn.1 seems to be deleted right
  after it was created, so it cannot be installed. So `make mtn.1` does
  create and delete the file, but when I execute the commands of that
  target in my own shell, mtn.1 persists. Weird, but a minor.

I'm currently executing make check and will report the results of that
tomorrow.

Thomas.

PS: German translation has been updated.

--
GPG-Key 0x160D1092 | [hidden email] | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Thomas Keller
Thomas Keller schrieb:
> I'm currently executing make check and will report the results of that
> tomorrow.

Faster than I thought, unit-tests ran through, with one error in
dates_roundtrip_localtimes, relevant tester.log output follows:


parsing date 'Fri Dec 13 20:45:51 1901' with format '%c'
localtime 1901/12/13 20:45:51 WD 5 YD 0 DST -1
-1 seconds UTC since unix epoch
Encountered an error while musing upon the following:
saving current work set: 3 items
finished saving work set
contents of work set:
Current work set: 3 items
----- begin 'system_flavour' (in virtual void sanity::initialize(int,
char **, const char *), at src/sanity.cc:119)
Darwin 13.1.0 Darwin Kernel Version 13.1.0: Wed Apr  2 23:52:02 PDT
2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64
-----   end 'system_flavour' (in virtual void sanity::initialize(int,
char **, const char *), at src/sanity.cc:119)
----- begin 'cmdline_string' (in virtual void sanity::initialize(int,
char **, const char *), at src/sanity.cc:133)
'/Users/thomas/Entwicklung/Open
Source/net.venge.monotone/test/bin/unit_tester',
'dates:roundtrip_localtimes'
-----   end 'cmdline_string' (in virtual void sanity::initialize(int,
char **, const char *), at src/sanity.cc:133)
----- begin 'string(lc_all)' (in virtual void sanity::initialize(int,
char **, const char *), at src/sanity.cc:138)
C
-----   end 'string(lc_all)' (in virtual void sanity::initialize(int,
char **, const char *), at src/sanity.cc:138)

test/unit/tests/../../../src/dates.cc:493: detected user error,
'E(tb.tm_sec == check.tm_sec && tb.tm_min == check.tm_min && tb.tm_hour
== check.tm_hour && tb.tm_mday == check.tm_mday && tb.tm_mon ==
check.tm_mon && tb.tm_year == check.tm_year && tb.tm_wday ==
check.tm_wday && tb.tm_yday == check.tm_yday && tb.tm_isdst ==
check.tm_isdst)' violated
UNCAUGHT EXCEPTION: recoverable_failure: misuse: date 'Fri Dec 13
20:45:51 1901' is out of range and cannot be parsed
Test dates:roundtrip_localtimes failed.


This test never failed on me in earlier OS X versions, seems as if
something changed.


The functional test suite ran through, expect one test as well,
ssh_agent. Here the ssh-agent is locally found and started, but monotone
doesn't seem to be able to connect to it:

mtn: warning: ssh_agent: failed to connect to agent: No such file or
directory
mtn: misuse: no ssh-agent is available, cannot add key
46ec58576f9e4f34a9eede521422aa5fd299dc50


And finally, the extra tests ran despite the mtn-cleanup test. This is
because of a path-quoting issue that I will fix in a few. I'll try to
have a closer look at the other two issues tomorrow.

Have a good night.
Thomas.


--
GPG-Key 0x160D1092 | [hidden email] | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Markus Wanner-2
In reply to this post by Thomas Keller
Thomas,

thanks for testing!

On 05/03/2014 01:39 AM, Thomas Keller wrote:
> I'm on 10.9 (Mavericks) here. I had no recent enough mtn installation
> around, so I had to copy sources and build from there.
>
> Things that I've stumbled upon  so far:
>
> * Don't use gcc from MacPorts to build, it will bring up weird linker
>   errors (see my previous post from February), but stick to plain clang
>   (which Apple advertises as gcc and g++ in the /usr/bin prefix)

Just out of curiosity: What clang version is it?

> * Monotone has no support for botan's "special" versioned package-
>   config file that botan seems to use since 1.10, so some more flag
>   magic was needed, namely
>   botan_CFLAGS="-I/opt/local/include/botan-1.10"
>   botan_LIBS="-lbotan-1.10"

Yeah, library.m4 isn't too clever about that, so all systems with newer
botan versions need these additional flags.

I'll either adjust the documentation or the script...

> * If gettext is not available, make (not make dist) fails with a
>   cryptic
>
>   make[2]: Circular po/sv.gmo <- po/sv.gmo dependency dropped.
>
>   I guess this is because of Makefile.am's
>
>   po/%.gmo: $(srcdir)/po/%.gmo
>         cp $< $@
>
>   which looks a bit fishy indeed.
Hm.. that's a good hint! I'll check.

`make -j$N` for any N bigger than 1 usually fails hanging at some txt2c
step, here. Up to date, I couldn't figure why and started to suspect a
bug in make. Maybe that's related. I see a small chance that's related...

> * make install failed for me, because mtn.1 seems to be deleted right
>   after it was created, so it cannot be installed. So `make mtn.1` does
>   create and delete the file, but when I execute the commands of that
>   target in my own shell, mtn.1 persists. Weird, but a minor.

Weird, indeed. Adding to my todo list: Makefile massage

> PS: German translation has been updated.

Thanks!

Markus



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Markus Wanner-2
In reply to this post by Thomas Keller
On 05/03/2014 02:08 AM, Thomas Keller wrote:
> test/unit/tests/../../../src/dates.cc:493: detected user error,
> 'E(tb.tm_sec == check.tm_sec && tb.tm_min == check.tm_min && tb.tm_hour
> == check.tm_hour && tb.tm_mday == check.tm_mday && tb.tm_mon ==
> check.tm_mon && tb.tm_year == check.tm_year && tb.tm_wday ==
> check.tm_wday && tb.tm_yday == check.tm_yday && tb.tm_isdst ==
> check.tm_isdst)' violated
> UNCAUGHT EXCEPTION: recoverable_failure: misuse: date 'Fri Dec 13
> 20:45:51 1901' is out of range and cannot be parsed
> Test dates:roundtrip_localtimes failed.

Ouch. Let's fix that before the release...

Anything special WRT timezone on that box, that you can think of? Or
with Mac OS X or MacPorts in general?

> This test never failed on me in earlier OS X versions, seems as if
> something changed.

I don't see any recent changes, i.e. not after the last release.

> The functional test suite ran through, expect one test as well,
> ssh_agent. Here the ssh-agent is locally found and started, but monotone
> doesn't seem to be able to connect to it:
>
> mtn: warning: ssh_agent: failed to connect to agent: No such file or
> directory
> mtn: misuse: no ssh-agent is available, cannot add key
> 46ec58576f9e4f34a9eede521422aa5fd299dc50

Maybe also an issue with spaces in the directory? I'm running a test, now.

> And finally, the extra tests ran despite the mtn-cleanup test. This is
> because of a path-quoting issue that I will fix in a few. I'll try to
> have a closer look at the other two issues tomorrow.

Thanks, much appreciated. I should be mostly around for today and still
hope to bundle a release tarball soon-ish.

Regards

Markus Wanner



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Markus Wanner-2
On 05/03/2014 09:45 AM, Markus Wanner wrote:
> On 05/03/2014 02:08 AM, Thomas Keller wrote:
>> mtn: warning: ssh_agent: failed to connect to agent: No such file or
>> directory
>> mtn: misuse: no ssh-agent is available, cannot add key
>> 46ec58576f9e4f34a9eede521422aa5fd299dc50
>
> Maybe also an issue with spaces in the directory? I'm running a test, now.

I built and tested from a directory with spaces without running into
this issue, so that's unlikely to be the cause (tested on Linux,
though). However, I found another one in bash_completion. It turned out
the test and the feature had issues. I fixed the test, but don't think
shell completion is release critical.

Regards

Markus Wanner



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Thomas Keller
In reply to this post by Markus Wanner-2
Markus Wanner schrieb:

> Thomas,
>
> thanks for testing!
>
> On 05/03/2014 01:39 AM, Thomas Keller wrote:
>> I'm on 10.9 (Mavericks) here. I had no recent enough mtn installation
>> around, so I had to copy sources and build from there.
>>
>> Things that I've stumbled upon  so far:
>>
>> * Don't use gcc from MacPorts to build, it will bring up weird linker
>>   errors (see my previous post from February), but stick to plain clang
>>   (which Apple advertises as gcc and g++ in the /usr/bin prefix)
>
> Just out of curiosity: What clang version is it?
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

>> * If gettext is not available, make (not make dist) fails with a
>>   cryptic
>>
>>   make[2]: Circular po/sv.gmo <- po/sv.gmo dependency dropped.
>>
>>   I guess this is because of Makefile.am's
>>
>>   po/%.gmo: $(srcdir)/po/%.gmo
>>         cp $< $@
>>
>>   which looks a bit fishy indeed.
>
> Hm.. that's a good hint! I'll check.
>
> `make -j$N` for any N bigger than 1 usually fails hanging at some txt2c
> step, here. Up to date, I couldn't figure why and started to suspect a
> bug in make. Maybe that's related. I see a small chance that's related...
I think this here is really just about a wrong rule in Makefile.am. It
survived for so long because most people already install needed
dependencies before letting out build system stumble upon it.

>> * make install failed for me, because mtn.1 seems to be deleted right
>>   after it was created, so it cannot be installed. So `make mtn.1` does
>>   create and delete the file, but when I execute the commands of that
>>   target in my own shell, mtn.1 persists. Weird, but a minor.
>
> Weird, indeed. Adding to my todo list: Makefile massage

Ok, thanks!
Thomas.

--
GPG-Key 0x160D1092 | [hidden email] | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Thomas Keller
In reply to this post by Markus Wanner-2
Markus Wanner schrieb:

> On 05/03/2014 02:08 AM, Thomas Keller wrote:
>> test/unit/tests/../../../src/dates.cc:493: detected user error,
>> 'E(tb.tm_sec == check.tm_sec && tb.tm_min == check.tm_min && tb.tm_hour
>> == check.tm_hour && tb.tm_mday == check.tm_mday && tb.tm_mon ==
>> check.tm_mon && tb.tm_year == check.tm_year && tb.tm_wday ==
>> check.tm_wday && tb.tm_yday == check.tm_yday && tb.tm_isdst ==
>> check.tm_isdst)' violated
>> UNCAUGHT EXCEPTION: recoverable_failure: misuse: date 'Fri Dec 13
>> 20:45:51 1901' is out of range and cannot be parsed
>> Test dates:roundtrip_localtimes failed.
>
> Ouch. Let's fix that before the release...
>
> Anything special WRT timezone on that box, that you can think of? Or
> with Mac OS X or MacPorts in general?
Not to my knowledge. I looked into the sources and saw that this
assertion is triggered when mktime returns -1, i.e. could not interprete
the single date components as a valid UNIX timestamp. I have to read the
platform's mktime(1) more closely to find out what the issue is here.

>> The functional test suite ran through, expect one test as well,
>> ssh_agent. Here the ssh-agent is locally found and started, but monotone
>> doesn't seem to be able to connect to it:
>>
>> mtn: warning: ssh_agent: failed to connect to agent: No such file or
>> directory
>> mtn: misuse: no ssh-agent is available, cannot add key
>> 46ec58576f9e4f34a9eede521422aa5fd299dc50
>
> Maybe also an issue with spaces in the directory? I'm running a test, now.
I don't know how the ssh-agent works in detail, but I thought that it
communicates over a local pip / socket of some sort that is referenced
by the SSH_AUTH_SOCK environment variable - and that pointed to a path
without spaces
(/var/folders/mb/xkzjkh3d5_g0bv46qhzlznv80000gn/T//ssh-wVNuN9lwzL5e/agent.45988).

>> And finally, the extra tests ran despite the mtn-cleanup test. This is
>> because of a path-quoting issue that I will fix in a few. I'll try to
>> have a closer look at the other two issues tomorrow.
>
> Thanks, much appreciated. I should be mostly around for today and still
> hope to bundle a release tarball soon-ish.

I have family time now, will look into it this evening.

Thomas.

--
GPG-Key 0x160D1092 | [hidden email] | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Markus Wanner-2
On 05/03/2014 04:31 PM, Thomas Keller wrote:
> Not to my knowledge. I looked into the sources and saw that this
> assertion is triggered when mktime returns -1, i.e. could not interprete
> the single date components as a valid UNIX timestamp. I have to read the
> platform's mktime(1) more closely to find out what the issue is here.

Sounds like a good hint. I'll have another look.

> I don't know how the ssh-agent works in detail, but I thought that it
> communicates over a local pip / socket of some sort that is referenced
> by the SSH_AUTH_SOCK environment variable - and that pointed to a path
> without spaces
> (/var/folders/mb/xkzjkh3d5_g0bv46qhzlznv80000gn/T//ssh-wVNuN9lwzL5e/agent.45988).

The local user's SSH_AUTH_SOCK is cleared before running tests. The
specific test starts its own ssh_agent to check against.

> I have family time now, will look into it this evening.

Enjoy! I have family-off time, now. Which I'm also enjoying ;-)

Markus



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Markus Wanner-2
In reply to this post by Thomas Keller
On 05/03/2014 01:39 AM, Thomas Keller wrote:
>   make[2]: Circular po/sv.gmo <- po/sv.gmo dependency dropped.
>
>   I guess this is because of Makefile.am's
>
>   po/%.gmo: $(srcdir)/po/%.gmo
>         cp $< $@
>
>   which looks a bit fishy indeed.

This starts to look a lot less fishy once you take VPATH builds into
account. Without it `make all` fails if $(srcdir) != $(builddir) with:

  *** No rule to make target `po/sv.gmo', needed by `all-nls'.  Stop.

And if $(srcdir) == $(builddir), dropping the dependency is just the
right thing to do.

So, I'm leaving the Makefile untouched. As it's clearly unrelated, I
don't feel like looking into #165, right now (the make -j hang).

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Thomas Keller
Markus Wanner schrieb:

> On 05/03/2014 01:39 AM, Thomas Keller wrote:
>>   make[2]: Circular po/sv.gmo <- po/sv.gmo dependency dropped.
>>
>>   I guess this is because of Makefile.am's
>>
>>   po/%.gmo: $(srcdir)/po/%.gmo
>>         cp $< $@
>>
>>   which looks a bit fishy indeed.
>
> This starts to look a lot less fishy once you take VPATH builds into
> account. Without it `make all` fails if $(srcdir) != $(builddir) with:
>
>   *** No rule to make target `po/sv.gmo', needed by `all-nls'.  Stop.
>
> And if $(srcdir) == $(builddir), dropping the dependency is just the
> right thing to do.
Well, I haven't told you all of the story. This is the rest of the
output in case srcdir == builddir, it fails the build!

make[2]: Circular po/sv.gmo <- po/sv.gmo dependency dropped.
cp  po/sv.gmo
usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file target_file
       cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file ...
target_directory
make[2]: *** [po/sv.gmo] Error 64
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Thomas.

--
GPG-Key 0x160D1092 | [hidden email] | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Markus Wanner-2
In reply to this post by Thomas Keller
On 05/03/2014 04:31 PM, Thomas Keller wrote:
> Not to my knowledge. I looked into the sources and saw that this
> assertion is triggered when mktime returns -1, i.e. could not interprete
> the single date components as a valid UNIX timestamp. I have to read the
> platform's mktime(1) more closely to find out what the issue is here.

I think I found a good hint in the a curl related page [0]:

  "Having a 64 bit time_t is not a guarantee that dates beyond
  03:14:07 UTC, January 19, 2038 will  work fine.  On  systems  with a
  64 bit time_t but with a crippled mktime(), curl_getdate will
  return -1 in this case."

Do you run a 32 or 64-bit Mac OS X? (Or is that a stupid question?)

I'll try to see what I can do with such a crippled mktime().

Regards

Markus Wanner


[0]: some man page for  curl_getdate:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/curl_getdate.3.html



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Markus Wanner-2
Thomas,

(or anybody on Mac OS X)

On 05/03/2014 08:40 PM, Markus Wanner wrote:
> I'll try to see what I can do with such a crippled mktime().

Can you please try the attached simple test program?

  $ g++ -o test test.cc
  $ ./test

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

test.cc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Thomas Keller
Markus Wanner schrieb:

> Thomas,
>
> (or anybody on Mac OS X)
>
> On 05/03/2014 08:40 PM, Markus Wanner wrote:
>> I'll try to see what I can do with such a crippled mktime().
>
> Can you please try the attached simple test program?
>
>   $ g++ -o test test.cc
>   $ ./test
I'm running a 64 bit OS X and your test program reports "mktime seems okay".

Thomas.

--
GPG-Key 0x160D1092 | [hidden email] | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Markus Wanner-2
On 05/03/2014 11:46 PM, Thomas Keller wrote:
> I'm running a 64 bit OS X and your test program reports "mktime seems okay".

Thanks. Surprises me. Although: I had a time zone issue in that test
program itself, though.

I could finally arrange for an Mac OS X box (Mountain Lion) that
thankfully reproduced the issue. I'm just about to commit a fix.
Attached a corrected variant of the test code. On my Mac OS X box it
yields: Lower boundary wrong (got -1)

I'm now looking into the ssh_agent failure.

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

test2.cc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Thomas Keller
Markus Wanner schrieb:

> On 05/03/2014 11:46 PM, Thomas Keller wrote:
>> I'm running a 64 bit OS X and your test program reports "mktime seems okay".
>
> Thanks. Surprises me. Although: I had a time zone issue in that test
> program itself, though.
>
> I could finally arrange for an Mac OS X box (Mountain Lion) that
> thankfully reproduced the issue. I'm just about to commit a fix.
> Attached a corrected variant of the test code. On my Mac OS X box it
> yields: Lower boundary wrong (got -1)
Yep, I get this as well. Just after I've sent my previous mail I looked
at the unit-test's code again and spotted this:

  // this is the valid range of dates supported by 32 bit time_t
  date_t start("1901-12-13T20:45:52");
  date_t end("2038-01-19T03:14:07");

So I guess the timestamp that it supposed to handle
("1901-12-13T20:45:51") should not be acceptable with a 32 bit time_t
and it should fail in such a case. But yeah, I'm just scratching on the
surface, you're way more fluent and faster than me in this area :)

Thomas.

--
GPG-Key 0x160D1092 | [hidden email] | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Markus Wanner-2
On 05/04/2014 12:06 AM, Thomas Keller wrote:
> So I guess the timestamp that it supposed to handle
> ("1901-12-13T20:45:51") should not be acceptable with a 32 bit time_t
> and it should fail in such a case.

Exactly.

While time_t itself is 64-bits, some mktime internals are not. Maybe
Apple just doesn't care about dates prior 1902. Maybe I should have done
the same rather than the extensive check. It's not like people use
monotone to handle such dates...

Regards

Markus Wanner



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: status of release 1.1

Thomas Keller
Markus Wanner schrieb:

> On 05/04/2014 12:06 AM, Thomas Keller wrote:
>> So I guess the timestamp that it supposed to handle
>> ("1901-12-13T20:45:51") should not be acceptable with a 32 bit time_t
>> and it should fail in such a case.
>
> Exactly.
>
> While time_t itself is 64-bits, some mktime internals are not. Maybe
> Apple just doesn't care about dates prior 1902. Maybe I should have done
> the same rather than the extensive check. It's not like people use
> monotone to handle such dates...
I can confirm that the dates_roundtrip_localtimes test now runs through
without issues. Well done!

Weird in the mktime semantics is really that - in the positive
directions - mktime can cope with dates beyond 2038, just not in the
negative direction with dates before 1902.

Anyways, thanks again,
Thomas.

--
GPG-Key 0x160D1092 | [hidden email] | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (267 bytes) Download Attachment