cnost zaregistrov�na: Praha ~ Identifikacn� c�slo (ICO):
498 11 894
-
-Original Message-
From: nut-upsuser-bounces+vaclavkrpec=eaton@lists.alioth.debian.org
[mailto:nut-upsuser-bounces+vaclavkrpec=eaton@lists.alioth.debian.org] On
Behalf Of nut-upsuser
Hello Charles,
thanks for the note, I'll take a look at it ASAP.
I have one virtual OS X myself; I guess I'll install devel.
packages and check for more such things...
I've qualified the C functions on purpose because
of the possibility to be confused with a local routine;
however if it's implem
Hello everybody,
1st (and yet incomplete) version of IPC support module for libnutconf
was pushed:
https://github.com/balooloo/nut/commit/0fbf351b5ee9899bd89cf17314727c69c2d5471c
The code contains lots TODO; I commit it mainly because I'll be off
on holiday for some time, so you may review and
Hello everybody,
basic UTs for libnutconf were pushed to balooloo/nut,
libconf branch:
https://github.com/balooloo/nut/commit/f453459419abf6c597d5d186494f91ed6f0e81aa
Note that the tests are not exhaustive; however, they
test the most prominent (sample) configuration settings
(de)serialisation.
Hello everybody,
so, here's the summary of my progress (note that it also includes a few items
to discuss, so I'm cc-ing this to nut-upsdev as well).
I. The planning:
1/ libnutconf:
The core (i.e. config. classes and their (de)serialisers) is coded, UT in
progress.
Signalisation shall follow; I
Hello fellow developers,
as you may have noticed from a few e-mails in the past,
there is a new NUT library in development these days.
It should be part of the NUT platform API in the future
and I'd like to present the status of work, hereby.
1/ The library shall be responsible of NUT configurat
Hello everybody,
(de)serialisation methods of all the currently existing config. classes
were pushed to balooloo/nut, libconf branch:
https://github.com/balooloo/nut/commit/df8b584c7fef71741b33bff11a482a103360250e
Please note that the deserialisation methods should work, however
they are quite
Hello gentlemen,
support for upsd.users confg. file was pushed to balooloo/nut,
libconf branch:
https://github.com/balooloo/nut/commit/8755ca7e1313b59d3c23740b4a5dc73a362b07a2
Regards,
vasek
--
Václav Krpec
Network UPS Tools project
Eaton Opensource Team
-
Eato
Hello fellow developers,
yesterday, I was thinking about how to implement specific config.
attributes accessors in section-based nut config. files so that
it's nice to use and consistent with NutConfiguration, UpsmonConfiguration
and UpsdConfiguration config. classes (where it's done via Settable
Hello everybody,
I've just noticed that POWERDOWNFLAG defaults to
/etc/killpower in upsmon.conf.
I believe that such files belong to the /run sub-tree.
Not only because it's not a config. file; mainly because
many embedded systems actually have most of the FS
read-only and have only the /tmp, /v
Hello Arnaud,
OK rev. 3775 adds support for date %s format checking
+ its usage is no longer disabled for Solaris, explicitly.
vasek
Eaton Elektrotechnika s.r.o. ~ S�dlo spolecnosti, jak je zaps�no v rejstr�ku:
Kom�rovsk� 2406, Praha 9 - Horn� Pocernice, 193
OK, so I’ll modify it so that it only uses Perl if date bin. desn’t
support the %s format string.
that would indeed be the most suitable approach.
do you need some help for the configure test?
Couldn’t I just do something like this?
date +%s | grep -q '^[0-9]*$' && date_s_works=”yes”
vasek
please note that revisions 3771 and 3772 conclude nut_clock_*
development (including UTs):
my conclusion was that nut_clock devs were completed with 3772, and only the
QRT side was remaining.
but that last requires:
1) that I provide you with a procedure to setup QRT (and this requires me to
pus
Hello everybody,
just a few notes to the doxygen X man issue:
1/ AFAIK doxygen can generate man pages, so why don't
we just generate them and decide then whether they
are ill fitted or usable...
2/ I'd definitely use doxygen when possible; I mean I don't
know any alternative that's abl
Hello gents,
correct me if I'm wrong, but I consider including
autoconf-generated config.h into publicly visible
project headers (i.e. in a dev. package) quite
bad habit---just like net-snmp package does on Fedora
and Solaris.
(Btw, does anyone know why it's like that only on those
2 systems? At
Hello Arnaud, Charles,
regarding the nut_clock_* iface unit testing,
I came to the following conclusion:
1/ It is IMO generally impossible to do deterministic
unit test; the problem in question is inherently
non-deterministic (I mean non-det. by nature).
Justification: the main reason is that we
Hello gents,
I just have a quick question: yesterday, I was doing some UTing with upsmon
and I've noticed that I always get 2 upsmon daemons; is that intentional?
Why?
Thanks,
vasek
--
Václav Krpec
Software Developer
Network UPS Tools project
Eaton Opensource Team
Eaton European Innovation Cen
Hi Arnaud,
The below link will provide you a good summary of the situation, what we can do
and how.
AFAICT, there is no way on HPUX (and some other older Unix) to use
clock_gettime with CLOCK_MONOTONIC, but CLOCK_REALTIME (which is functionally
different).
gethrtime (high resolution time) seem
essage-
> From: nut-upsuser-bounces+vaclavkrpec=eaton@lists.alioth.debian.org
> [mailto:nut-upsuser-bounces+vaclavkrpec=eaton@lists.alioth.debian.org]
> On Behalf Of nut-upsuser-requ...@lists.alioth.debian.org
> Sent: Tuesday, October 09, 2012 2:00 PM
> To: nut-upsuser@
Hi Charles,
> I don't think we should ignore an EINVAL error, and we should fall back to
> gettimeofday() in that case. (I know gettimeofday is deprecated, but if
> CLOCK_MONOTONIC isn't quite right, then gettimeofday should work.)
Aw, I think I might have been too fast with condemning gettimeo
> > Clarification: I do clock_gettime(CLOCK_MONOTONIC, &tm) and if that
> > fails with EINVAL and the user requested MONOTONIC_PREF (i.e.
> > fall-back to RTC is allowed), I do another
> > clock_gettime(CLOCK_REALTIME, &tm) which should always work.
> >
> > However, I wonder whether this isn't too
Hello Charles,
you can take a look at the code in branches/Vaclav/common/clock.c vi viewvc.
Clarification: I do clock_gettime(CLOCK_MONOTONIC, &tm) and if that
fails with EINVAL and the user requested MONOTONIC_PREF (i.e. fall-back
to RTC is allowed), I do another clock_gettime(CLOCK_REALTIME, &
Hello everybody,
during the last build (#380) on HPUX (eaton-hpux11-pa-risc buildslave),
I've noticed the following warning when compiling upsd:
../../server/upsd.c:417: warning: implicit declaration of function 'fromhost'
fromhost is either an alias for sock_host or declared as
extern void fro
> From: Charles Lepple [mailto:clep...@gmail.com]
> On Oct 3, 2012, at 8:41 AM, wrote:
>
> > I see, however I think that it's actually better to do the encapsulation.
> > Justification:
> >
> > 1/ We need to alter widespread code, anyway (I mean if we used
> > clock_gettime already and just need
Hi Arnaud,
I see, however I think that it’s actually better to do the encapsulation.
Justification:
1/ We need to alter widespread code, anyway
(I mean if we used clock_gettime already and just needed to implement it
for platforms that don’t have it, using the autoconf macro would be nice
and fas
Hello Baruch,
thanks for your comment.
OK, I’ll just aim to create an implementation of all-purpose
portable clock with the possibility of monotonic/ real-time
operation (where available).
It still should be encapsulated, though. Unlike time() and
difftime(), clock_*time() interface (or at least
Hello everybody,
I'm working on the "Use difftime for time comparison" bug (#313634).
Charles directed me to the other one "Use monotonic clock for monitoring"
attended to by Baruch; I believe that's very good idea, however I'd use a bit
more encapsulated & general approach:
1/ I'd create an o
27 matches
Mail list logo
