No, this is not possible. I put this on the wish list. 

 Hello,

Can anyone please send me, or publicly provide, working Ubuntu 10.10 binaries (64-bit) for ELOG?

I have compiled and installed the program. While the core functionalities are OK, I have run into irritating bugs in filtering and config editing that are not present in the online demo (but are in my local demo and logbook).

Hence I suspect compilation to be the cause.

For the curious:

• Saving the config within ELOG scrambles the elog.conf file

Hmm actually that last bug is also present in the demo. Any hope of fixing that?

True, some posts may not match the filters, leaving replies "orphan". I suggest that any orphan reply be either attached to the nearest upper level, or if not possible, be styled as a post instead of a reply (no arrow or indent) so as not to mistake it for a reply to the message above.

The benefit would be to be able to follow threads matching certain categories.

I have just installed elog 2.8.1 on my OpenBSD 4.8 server (I've added the necessary Makefile patch to "Contributions"). Everything seems to work fine, however, I ran into a very odd problems with the dates of the logbook entries: When I start a new entry, the current date/time is displayed correctly. When I submit the entry and look at it again, the date has changed to some value in 1996 . I've checked the actual logbook file and there, the entry has a Date line like this:

Date: Thu, 03 Feb 2011 23:53:28 -13049141
 

The "-13049141" looks very suspicious to me - but I have no idea whatsoever why this happens. I had elogd running with -v, but that did not give me any hints. Any ideas how to debug/resolve this would be much appreciated...

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
}

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

Hi all,

We've been happily using ELOG for years, but ran into an odd problem when replacing the old Solaris server that ran the ELOG with a newer box running Ubuntu. 

Basically, when I try to search the log, the URL seems to be malformed. I.e. the form produces the query string:

?mode=summvry&reverse=0&reverse=1&npp=35&m&y&Authorthor=ericq

Instead of a functional one like:

?mode=summary&reverse=1&npp=35&Author=ericq

We're running v2.8.1, since we like using the global write password mode; our log is viewable here: http://nodus.ligo.caltech.edu:8080 Any ideas what could've gone wrong? Installation was pretty straightforward, the code compiled happily on the ubuntu machine. 

Incidentally, I notice this logbook is running V3, using CKeditor. Any hints when these might be available for public use?

Thanks!

Old versions are not supported any more. I only can fix bugs in the current version. Probably the bug you report is already gone (just give it a try). If you need the global write password mode, you can enable guest read access to your logbook and define a single use with the write password, that's then almost equivalent.

/Stefan