| Stefan Ritt wrote: |
|
The problem is most probably related to the time zone. elogd contains a function:
/* workaround for wong timezone under MAX OSX */
long my_timezone()
{
#if defined(OS_MACOSX) || defined(__FreeBSD__)
time_t tp;
time(&tp);
return -localtime(&tp)->tm_gmtoff;
#else
return timezone;
#endif
}
from which you can see that there is a different behavior between different Linux flavors and OSX/FreeBSD. Maybe you need an additional
|| defined(__OpenBSD__)
if the pre-compiler directive __FreeBSD__ is not defined on your system.
[...]
|
BINGO! That was it - thank you! I've added the || defined(__OpenBSD__) in the place you described above and now the dates are correct. While I was at it, I also had a look at what other ifdefs there are for FreeBSD and the only other one I found was also in elogd.c:
#if defined (_BSD_VA_LIST_) && defined (__FreeBSD__)
I'm far from being a C programmer, but I did some quick and dirty compile tests with various ifdefs set and apparently, _BSD_VA_LIST_ is not set on OpenBSD, so I guess that this statement does not need modification. I will keep my eyes peeled for strange behaviour, though... 
Cheerio,
Thomas
P.S.: One thing I noticed is that the OpenBSD variant of gcc throws these warnings when compiling elogd.c:
gcc -g -funroll-loops -fomit-frame-pointer -W -Wall -DHAVE_SSL -I../mxml -o elogd src/elogd.c crypt.o regex.o mxml.o strlcpy.o -lcrypto -lssl
/tmp//ccHhMZfy.o(.text+0xd2f): In function `int_vasprintf':
src/elogd.c:826: warning: vsprintf() is often misused, please use vsnprintf()
/tmp//ccHhMZfy.o(.text+0xae8): In function `xstrdup':
src/elogd.c:736: warning: strcpy() is almost always misused, please use strlcpy()
/tmp//ccHhMZfy.o(.text+0x13c7): In function `my_shell':
src/elogd.c:1197: warning: sprintf() is often misused, please use snprintf()
/tmp//ccHhMZfy.o(.text+0xf0ae): In function `el_correct_links':
src/elogd.c:5178: warning: strcat() is almost always misused, please use strlcat()
I'm not certain whether this is specific to this gcc variant, but I seem to remember that the OpenBSD folks added some extra warnings and suchlike as part of their overall code audit, so I thought I'd mention it. |
I just ran into an odd bug with conditional attributes: If I add a certain attribute to "Required Attributes", none of the conditionals will work anymore. I have tried to create a small logbook definition that will demonstrate the problem (the original logbook is more complex and uses two sets of conditionals, both of which will be disabled when the bug hits):
; General settings
Menu commands = List, New, Edit, Duplicate, Delete, Reply, Select, Move to, Download, Find, Logout, Help, Config,Admin
List Menu commands = New, Select, Find, Logout, Help, Config, Admin, Import, Download
Date Format = %d/%m/%Y
List conditions = 1
List display = Edit, Type, Created, StatusA, StatusB, Archived, Test Text, Public?
; Attributes
Attributes = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
Required Attributes = Type
; Attribute Types
Type Created = date
Type Archived = date
; Options & Tooltips
Options Type = Type1{0}, Type2{1}
Options StatusA = Status-A-red, Status-A-orange, Status-A
Options StatusB = Status-B-red, Status-B-orange, Status-B
Options Public? = yes,no
; Conditionals
{0}Show Attributes Edit = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
{1}Show Attributes Edit = Type, Created, StatusA, Archived, Test Text, Public?
The above logbook definition works. However, if I replace the Required Attributes = Type with Required Attributes = Type, Public?, the conditionals will no longer work. I can see the difference in the reactions of the browser - with the extra attribute, nothing happens when I change "Type". Without, the browser will spring into action and reload as soon as I change "Type". I've tested this with both Firefox 3.6.13 and Konqueror 4.4.5 on Kubuntu 10.04 as clients. Fortunately, this is not a showstopper for me, as it is not mandatory to have this attribute defined as required, but I find it a weird issue nonetheless.
Cheerio,
Thomas
P.S.: I'm currently running the latest SVN version of elogd on OPenBSD as I ran into the same problem as described in Message 66984. The above problem also happens with the 2.8.1 I was using before. Some feedback: The SVN version compiled and ran without any further intervention on OpenBSD - very nice! |