| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
2143
|
Tue Feb 20 18:41:31 2007 |
 | Martin Killenberg | martin.killenberg@web.de | Comment | Linux | 2.6.4 | Hardcoded Path in Makefile |
I tried to compile ELOG on Scientific Linux Cern 4.4 and found that make quits because uname is not located in /usr/bin (like it is hardcoded in the makefile) but in /bin.
Later I found that this is only the case in the svn version, in the "latest.tar.gz" from 2007/02/20 the path is /bin.
Why do you have the absolute path in the Makefile? uname should be in the default path on any system. (The same applies to "rm")
I also was confused that you only provide one rpm Package (except for debian) without mentioning for which distribution. You try to avoid dependencies, but the elogd is linked against the basic libraries libc and ld-linux, which might vary. |
|
2144
|
Tue Feb 20 21:10:28 2007 |
 | Stefan Ritt | stefan.ritt@psi.ch | Comment | Linux | 2.6.4 | Re: Hardcoded Path in Makefile |
| Martin Killenberg wrote: | I tried to compile ELOG on Scientific Linux Cern 4.4 and found that make quits because uname is not located in /usr/bin (like it is hardcoded in the makefile) but in /bin.
Later I found that this is only the case in the svn version, in the "latest.tar.gz" from 2007/02/20 the path is /bin.
Why do you have the absolute path in the Makefile? uname should be in the default path on any system. (The same applies to "rm")
I also was confused that you only provide one rpm Package (except for debian) without mentioning for which distribution. You try to avoid dependencies, but the elogd is linked against the basic libraries libc and ld-linux, which might vary. |
Ups. The hard-coded /usr/uname somehow sneaked in from some temporary test. I removed it in the current SVN.
Indeed the RPM package I provide is built under Scientific Linux. The Debian port is done by someone else. Unfortunately I don't have ten boxes with all possible distributions laying around, so my possibilities are quite limited and I depend on third party help. If you want to contribute additional RPMs you are welcome. |
|
65739
|
Tue Feb 12 23:57:52 2008 |
| Jochen Krempel | krempel@ill.fr | Comment | All | 2.7.2-2 | Re: Absolut links for images in FCK Editor |
| Stefan Ritt wrote: |
|
| Jochen Krempel wrote: |
|
We use ELOG inside a local network, but we want to allow access also from outside the firewall.
The suggested solution from Elog Admin Guide worked fine until version ELOG V2.6.5-1844 (essentially without FCK Editor):
ssh -L 1234:your.server.name:8080 your.firewall.name
firefox http://localhost:1234/
Howerver, since the update to ELOG V2.7.1-2002 the FCK Editor uses absolute links to insert images.
An image uploaded from the local network will have an address like:
http://your.server.name:8080/logbookname/080207_101110/Picture.jpg
while the same image uploaded through the firewall tunnel will have a link like:
http://localhost:1234/logbookname/080207_101110/Picture.jpg
Obviously images uploaded from outside are not visible from inside and vice versa.
Is it possible to convince FCK Editor to use relative links?
PS
ELOG is great!!
|
I fixed this in SVN revision #2038.
|
Thank you for the quick support! |
|
66096
|
Wed Dec 3 22:57:13 2008 |
 | mike cianci | mike2.cianci@comcast.net | Comment | Windows | | Re: Multi attribute email notification |
Your suggestion worked GREAT (like always)
| Stefan Ritt wrote: |
|
| mike cianci wrote: |
|
What I would like to do is:
If attribute "A" and attribute "B" - send email to person #1
If attribute "A" and attribute "C" - send email to person #2
(I apologize if this in the documentation. I have looked at the "Email" section and have either missed it or don't understand it. Thank you for the help)
|
This is not implemented, you only can test on a single attribute. There might be a possibility with conditional attributes, but I have never tried this out.
|
|
|
66142
|
Sun Jan 11 00:02:34 2009 |
| John Rouillard | rouilj+elog@cs.umb.edu | Comment | Windows | 2.7.5 | Re: Multi attribute email notification |
| mike cianci wrote: |
|
Your suggestion worked GREAT (like always)
|
Could you post an example of what you used? |
|
66201
|
Mon Feb 9 07:58:46 2009 |
| mike cianci | mike2.cianci@comcast.net | Comment | Windows | 2.7.5 | Re: Multi attribute email notification |
| John Rouillard wrote: |
|
| mike cianci wrote: |
|
Your suggestion worked GREAT (like always)
|
Could you post an example of what you used?
|
Sorry, it took me so long to respond. I didn't notice your request.
Attributes = Instrument, Notify Lead Tech
Options Instrument = Olympus, Beckman
Options Notify Lead Tech = Yes{a}, No {b}
{a}Email Instrument Olympus = John@lab.net (i.e. if it is "Yes" and "Olympus" - John gets an email)
{a}Email Instrument Beckman = Mary@lab.net (i.e. if it is "Yes" and "Beckman" - Mary gets an email) |
|
66202
|
Mon Feb 9 07:58:58 2009 |
| mike cianci | mike2.cianci@comcast.net | Comment | Windows | 2.7.5 | Re: Multi attribute email notification |
| John Rouillard wrote: |
|
| mike cianci wrote: |
|
Your suggestion worked GREAT (like always)
|
Could you post an example of what you used?
|
Sorry, it took me so long to respond. I didn't notice your request.
Attributes = Instrument, Notify Lead Tech
Options Instrument = Olympus, Beckman
Options Notify Lead Tech = Yes{a}, No {b}
{a}Email Instrument Olympus = John@lab.net (i.e. if it is "Yes" and "Olympus" - John gets an email)
{a}Email Instrument Beckman = Mary@lab.net (i.e. if it is "Yes" and "Beckman" - Mary gets an email) |
|
66504
|
Mon Aug 10 21:07:15 2009 |
 | David Pilgram | David.Pilgram@epost.org.uk | Comment | Linux | 2.7.7-2251 | Comment on: Alphabetize Quick Option filter |
(For some reason I could not add this in Dennis's thread.)
I like this new feature, BUT
I happen to have two Options: Options System, and Options Status.
System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to.
Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
this is made up)
Options System: 3.1, NT, 2000, XP, Vista
where the natural order here is chronological.
Perhaps the configuration file option could be more specific, for example
Sort attribute Options Status = 1
which would then NOT sort Options System. If both are needed to be sorted, both should be specified, or back to
the original syntax which defaults to sort *all* Options. |