convert: unrecognized option '-set', posted by Devin Bougie on Mon Jan 26 22:01:07 2009
|
Hello,
We are now running elog-2.7.5 in a Scientific Linux 4 (RHEL4) system, which uses ImageMagick 6.0.7.1. After uploading an image, the image
manipulation buttons don't work and complain:
convert: unrecognized option '-set'
We are using an RPM built from source, and it looks like I should be able to just change "-set comment ..." to "-comment" as in:
------
[dab66@lnx100 tmp]% diff elogd.c elogd.c.new
22601c22601
< sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -set comment ' %d' '%s'", file_name, new_rot,
---
> sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -comment ' %d' '%s'", file_name, new_rot,
22607c22607
< sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -set comment ' %d' '%s'", file_name, new_rot,
---
> sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -comment ' %d' '%s'", file_name, new_rot,
22618c22618
< sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -set comment ' %d' '%s'", file_name, cur_rot,
---
> sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -comment ' %d' '%s'", file_name, cur_rot,
22624c22624
< sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -set comment ' %d' '%s'", file_name, cur_rot,
---
> sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -comment ' %d' '%s'", file_name, cur_rot,
------
Is there any better way for us to fix this, or is anything else needed?
Thanks,
Devin |
Re: convert: unrecognized option '-set', posted by Stefan Ritt on Tue Jan 27 09:19:22 2009
|
> Hello,
>
> We are now running elog-2.7.5 in a Scientific Linux 4 (RHEL4) system, which uses ImageMagick 6.0.7.1. After uploading an image, the image
> manipulation buttons don't work and complain:
> convert: unrecognized option '-set'
>
> We are using an RPM built from source, and it looks like I should be able to just change "-set comment ..." to "-comment" as in:
> ------
> [dab66@lnx100 tmp]% diff elogd.c elogd.c.new
> 22601c22601
> < sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -set comment ' %d' '%s'", file_name, new_rot,
> ---
> > sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -comment ' %d' '%s'", file_name, new_rot,
> 22607c22607
> < sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -set comment ' %d' '%s'", file_name, new_rot,
> ---
> > sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -comment ' %d' '%s'", file_name, new_rot,
> 22618c22618
> < sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -set comment ' %d' '%s'", file_name, cur_rot,
> ---
> > sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -comment ' %d' '%s'", file_name, cur_rot,
> 22624c22624
> < sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -set comment ' %d' '%s'", file_name, cur_rot,
> ---
> > sprintf(cmd, "convert '%s' -rotate %d -thumbnail %d -comment ' %d' '%s'", file_name, cur_rot,
> ------
>
> Is there any better way for us to fix this, or is anything else needed?
Well, I believe your modification won't work. I just tried it with ImageMagick 6.3.8 and it failed. Try to rotate your picture four times, and
it should be back to the old position. When I use "-comment" instead "-set comment" on a PNG file, this did not work. From the man page it
tells me:
Version: ImageMagick 6.3.8 01/25/08 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC
Usage: convert [options ...] file [ [options ...] file ...] [options ...] file
Image Settings:
...
-comment string annotate image with comment
...
Image Operators:
...
-set property value set an image property
...
So indeed "-comment" and "-set comment" are two different things. I'm afraid you have to upgrade your ImageMagick package in order to make
this work. |
Long cookie content is not handled properly., posted by Simon Patton on Tue Apr 14 22:51:15 2009
|
I discovered the infinite loop in 2.7.5 which can happen when a cookie's content is longer that the cookie array
designed to hold it. I also note that this issue has been addressed in 2.7.6, but the solution does not appear
to be correct and it can end up completely confusing the cookie extraction.
In 2.7.5 the code was:
for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; )
if (i < (int) sizeof(cookie)-1)
cookie[i++] = *p++;
While in 2.7.6 is became:
for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n';)
if (i < (int) sizeof(cookie) - 1)
cookie[i++] = *p++;
else
break;
This leaves 'p' pointing to the middle of the cookie's content and I can not see that this is corrected in the loop (sorry if I've missed that).
The solution I used to patch 2.7.5 was the following:
for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; ++p)
if (i < (int) sizeof(cookie)-1)
cookie[i++] = *p;
which simply truncates the contents of the cookie (which is assumed not to be an elogd cookie) but leaves 'p' in the right place to extract the next one. |
|
Re: Long cookie content is not handled properly., posted by Stefan Ritt on Wed Apr 15 09:26:37 2009
|
| Simon Patton wrote: | I discovered the infinite loop in 2.7.5 which can happen when a cookie's content is longer that the cookie array
designed to hold it. I also note that this issue has been addressed in 2.7.6, but the solution does not appear
to be correct and it can end up completely confusing the cookie extraction.
In 2.7.5 the code was:
for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; )
if (i < (int) sizeof(cookie)-1)
cookie[i++] = *p++;
While in 2.7.6 is became:
for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n';)
if (i < (int) sizeof(cookie) - 1)
cookie[i++] = *p++;
else
break;
This leaves 'p' pointing to the middle of the cookie's content and I can not see that this is corrected in the loop (sorry if I've missed that).
The solution I used to patch 2.7.5 was the following:
for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; ++p)
if (i < (int) sizeof(cookie)-1)
cookie[i++] = *p;
which simply truncates the contents of the cookie (which is assumed not to be an elogd cookie) but leaves 'p' in the right place to extract the next one. |
You're absolutely right about that. I incorporated your patch into revision #2192. |
|
Auto-increment substitutions broken with records for multiple days, posted by Richard Stamper on Wed Jun 24 15:02:49 2009
|
With a logbook defined by
[test]
Theme = default
Comment = Test of auto-increment
Attributes = Batch
Subst Batch = %Y%m%d-##
the auto-incrementing of the Batch attribute within dates works when the logbook contains only entries for
today's date but otherwise will give a batch number of "01" for each entry.
Changing line 8714 of elogd.c as follows, from:
/* if date part changed, start over with index */
if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
old_index = 0;
else
/* retrieve old index */
if (atoi(attrib[index] + loc) > old_index)
old_index = atoi(attrib[index] + loc);
to
/* if date part changed, start over with index */
if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
break; /* <------------- */
else
/* retrieve old index */
if (atoi(attrib[index] + loc) > old_index)
old_index = atoi(attrib[index] + loc);
appears to fix this bug when I test it. This code is inside a loop stepping back through all log entries, and
the variable old_index is already set to zero before the loop. The existing code resets old_index whenever the
prefix of the attribute string (containing a date) does not match the "current" value of that prefix as found in
retstr (set using strftime). So, if there are any records for dates other than today then old_index is reset
and attribute values will be set with the counter = (old_index+1) = 1. The modified version stops comparisons
once a different date is seen, but assumes that records are date ordered. An alternative patch:
/* if date part matches */
if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) == 0)
/* retrieve old index */
if (atoi(attrib[index] + loc) > old_index)
old_index = atoi(attrib[index] + loc);
does not make this assumption and also appears to work OK when I test it. |
|
Re: Auto-increment substitutions broken with records for multiple days, posted by Stefan Ritt on Thu Jun 25 10:09:18 2009
|
> An alternative patch:
>
> /* if date part matches */
> if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) == 0)
> /* retrieve old index */
> if (atoi(attrib[index] + loc) > old_index)
> old_index = atoi(attrib[index] + loc);
>
> does not make this assumption and also appears to work OK when I test it.
Yes, this is the right one, it searches all entries to have the same date than the current one, and then looks for the
largest index which will be stored in old_index and later incremented by one. I committed your patch to the
repository. Thanks a lot. |
elogd keeps crashing, any thoughts?, posted by Allen on Thu Dec 3 20:25:50 2009
|
We are trying to track down an issue where elogd just stops, and I cannot seem to find a cause.
In the logs, I see:
Dec 3 14:01:23 nissrv18a kernel: [419738.139675] elogd[32003]: segfault at 4 ip 00007f183b19b560 sp 00007fff79f5e278 error 4
in libc-2.10.1.so[7f183b119000+166000]
Any thoughts? |
|
Re: elogd keeps crashing, any thoughts?, posted by Stefan Ritt on Fri Dec 4 23:45:56 2009
|
| Allen wrote: |
|
We are trying to track down an issue where elogd just stops, and I cannot seem to find a cause.
In the logs, I see:
Dec 3 14:01:23 nissrv18a kernel: [419738.139675] elogd[32003]: segfault at 4 ip 00007f183b19b560 sp 00007fff79f5e278 error 4
in libc-2.10.1.so[7f183b119000+166000]
Any thoughts?
|
I need more information about that. Please have a look at Faq #19. |
|