/* 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
}

 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!

 Thanks Stefan, I'll try that. It's strange, though: At work, we're running 2.7.6 (and have used older versions in the past) and we have several logbooks with each at least one or two attributes with '?' and never had a problem with conditionals. Hence my surprise when this suddenly hit me with 2.8.1+ at home. Removing the '?' would be quite some work, as I'd have to change all logbooks and the associated data (the latter could probably be done with "rpl", I hope). I'll think about it.

I have an issue where not all users are able to log into their sessions and they are still settling on the login page

BUG#1
Given:

Attributes = Category, Status, Started, Finished, Activity, Headline
Type Started = date
Type Finished = date
Options Status = 1-To Do{1}, 2-Opened{2}, 3-Closed{3}, 4-Suspended{4}
{2} Preset Started = $date
{3} Preset Finished = $date
{4} Preset Finished = $date

There seems to be no setting of Date format (or Time format?) that gives a
meaningful value to attributes Started or Finished.  Even "Date format = %s"
- which gives number of seconds since 1970 - gives bad results.

BUG#2
In single entry view, elog returns an unformatted date value for "Type =
date" attributes - even when it has been manually entered with the date picker.

> > BUG#1
> 
> Has been fixed. New version under CVS.

Thanks for that, Stefan.

> > BUG#2
> > In single entry view, elog returns an unformatted date value for "Type =
> > date" attributes - even when it has been manually entered with the date picker.
> 
> Can't reproduce that. Used your config, got the display attached.

Nor can I in the new version.  Forgive me if I don't investigate further. ;-)

> Has been fixed in revision 1.492.

Thanks, Stefan.