> It seems to work nice to me.
> Just another suggestion: I think it would be better to insert a commented out
> example for all allowed parameters in the distributed  /etc/default/elog

Thanks for the test.  Please note that, /etc/default/elog is partially auto
created during the installation.  All options except PIDFILE and CONFFILE are
currently listed (as configured or commented out).  If you didn't see these
options (after the update), there must be a problem.   Did you mean the lack of
PIDFILE and CONFFILE in the default file?

> When an attached image name contains a space in its filename and attachment
> display is enabled elog builds a wrong url to the image:
> 
> http://arcolog.roma2.infn.it:8080/ARCO/050309_170709/peeling+002.jpg
> 
> instead of the correct one:
> 
> http://arcolog.roma2.infn.it:8080/ARCO/050309_170709_peeling+002.jpg
> 
> The more annoing thing is that elogs hangs on this. a strace shows a select
> on fd n°3 and 5 that loops forever (returning a timeout error):
> 
> send(4, "<141>Mar 23 11:36:25 elogd[22189"..., 35, 0) = 35
> rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
> select(1024, [3 5], NULL, NULL, {1, 0}) = 0 (Timeout)
> select(1024, [3 5], NULL, NULL, {1, 0}) = 0 (Timeout)
> 
> 
> May be the better solution is, after fixing the bug for backward
> compatibility with already uploaded images, to implement a forced characters
> substitution at upload time, replacing spaces and every character not in a
> "allowed chars" list with an underscore

A correction:
the url generated is correct, infact modifing by hand the names of the files and
the "Attachment:" entry in the .log all works fine

the same problem happens if the filename is, for example foo.JPG and not foo.jpg :
http://arcolog.roma2.infn.it:8080/ARCO/050221_171508/Graph3.JPG
loops forever

http://arcolog.roma2.infn.it:8080/ARCO/050221_171508/Graph3.jpg
works correctly


so, elog does not like spaces in filename and/or uppercase extensions. the
solution is, IMHO, to sanify the uploaded filename at uploading time :-)

When an attached image name contains a space in its filename and attachment
display is enabled elog builds a wrong url to the image:

http://arcolog.roma2.infn.it:8080/ARCO/050309_170709/peeling+002.jpg

instead of the correct one:

http://arcolog.roma2.infn.it:8080/ARCO/050309_170709_peeling+002.jpg

The more annoing thing is that elogs hangs on this. a strace shows a select
on fd n°3 and 5 that loops forever (returning a timeout error):

send(4, "<141>Mar 23 11:36:25 elogd[22189"..., 35, 0) = 35
rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
select(1024, [3 5], NULL, NULL, {1, 0}) = 0 (Timeout)
select(1024, [3 5], NULL, NULL, {1, 0}) = 0 (Timeout)


May be the better solution is, after fixing the bug for backward
compatibility with already uploaded images, to implement a forced characters
substitution at upload time, replacing spaces and every character not in a
"allowed chars" list with an underscore

> Hi to all,
> 
> I've prepared a new Debian package.  This version will probably be the one
> which you'll find in Sarge/stable.
> 
> There are some invasive changes in this version which call for a serious
> test.  In accordance with a suggestion, I've changed the configuration
> mechanism.  For details, please read the NEWS.Debian file attached.
> 
> Could the Debian users who follow this forum test it and give some feedback?
> You can download the package from the following link:
> 
>   http://l10n-turkish.alioth.debian.org/debian/elog_2.5.8+r1592-1_i386.deb
> 
> Thanks in advance for your participation,

It seems to work nice to me.
Just another suggestion: I think it would be better to insert a commented out
example for all allowed parameters in the distributed  /etc/default/elog

nice work :-)

Hi to all,

I've prepared a new Debian package.  This version will probably be the one
which you'll find in Sarge/stable.

There are some invasive changes in this version which call for a serious
test.  In accordance with a suggestion, I've changed the configuration
mechanism.  For details, please read the NEWS.Debian file attached.

Could the Debian users who follow this forum test it and give some feedback?
You can download the package from the following link:

  http://l10n-turkish.alioth.debian.org/debian/elog_2.5.8+r1592-1_i386.deb

Thanks in advance for your participation,

Stefan,

Oh. OK. I will keep tuned. It would be quite useful to have.

Mark
> > I have defined a new field called "Record Date" to accept the dates from a
> > previous logging system. I am not too concerned with the timestamp
> > associated with these old imported entries. But for new entries...
> > There is no way I am able enter/edit the time into my new field. They all
> > show as having a time of 12:00. What am I doing wrong? Here is a portion of
> > my config
> 
> Date is "date", and not "date-time" unfortunately. There is no way right now to
> enter a time. I plan however to add a new format "datetime", which allows that
> option. So stay tuned.
> 
> - Stefan

> I have defined a new field called "Record Date" to accept the dates from a
> previous logging system. I am not too concerned with the timestamp
> associated with these old imported entries. But for new entries...
> There is no way I am able enter/edit the time into my new field. They all
> show as having a time of 12:00. What am I doing wrong? Here is a portion of
> my config

Date is "date", and not "date-time" unfortunately. There is no way right now to
enter a time. I plan however to add a new format "datetime", which allows that
option. So stay tuned.

- Stefan

> I would like to increase the spacing between 'MOptions' choices. I have
> created a new theme and have been playing with the CSS stylesheet. But can't
> find how to increase this spacing. Having lots of fun otherwise!

Intersting question (meaning: I don't have an answer... (;-) )

The class which applies there is "attribvalue". You can increase the padding for
that class, but that only increases the space between all options and the cell
border, but not between them. I could put each MOption in a separate cell of a
subtable. Then one could increase the padding between them, but the layout would
be fixed, meaning that they are always left-to-right. As you can see in this
forum, the MOptions nicely place below each other if the screen is too narrow.
This functionality would be lost.

Maybe someone else has a clever solution?