#9905: Spkg logs should get timestamps
-----------------------------+----------------------------------------------
Reporter: justin | Owner: GeorgSWeber
Type: defect | Status: new
Priority: major | Milestone:
Component: build | Keywords:
Author: Justin Walker | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
-----------------------------+----------------------------------------------
Old description:
> Put timestamps into the spkg logs, both at the beginning and the end of
> each build run for the spkg in question.
>
> This aids both in debugging problems with the build and with evaluating
> performance issues in the build.
New description:
Put timestamps into the spkg logs, both at the beginning and the end of
each build run for the spkg in question.
This aids both in debugging problems with the build and with evaluating
performance issues in the build.
See also: #7183, #7188, #8385
--
Comment(by drkirkby):
Replying to [comment:2 leif]:
> I'd suggest using
> {{{
> #!sh
> date "+%F %T %z"
> }}}
> which is independent of the current locale, such that we get something
like:
> {{{
> SPKG BUILD STARTED: 2010-09-16 13:52:21 +0200
> ...
> SPKG BUILD FINISHED: 2010-09-16 13:52:30 +0200
> }}}
But that would be a portability problem, as %F is not in the
[http://www.opengroup.org/onlinepubs/009695399/utilities/date.html POSIX
specification for date]. Looking at the man page for date on a Linux
machine I see:
{{{
%F full date; same as %Y-%m-%d
}}}
So that would be an obvious improvement.
> Does anyone also want nanoseconds ({{{%N}}})? (I'm not sure how portable
that would be.)
Just take a look at
http://www.opengroup.org/onlinepubs/009695399/utilities/date.html and you
will find it is not portable.
> Opinions? Substitute "BUILD" by "INSTALLATION" (since we might also run
a test suite after successful installation)? Or should we add
''additional'' timestamps for checks?
I think it would be useful to add the output from 'uname -a' too, so when
people post logs, we know what system they were built on.
I probably have some other thoughts on this, but I'm very busy today and
don't have time to look at tickets in much detail. Just adding an odd
comment where I feel I can contribute something.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9905#comment:4>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
