| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
1686
|
Fri Feb 10 22:35:20 2006 |
 | Stefan Ritt | stefan.ritt@psi.ch | Question | Other | 2.6.1 | Re: compiling elog 2.6.1 on solaris platform |
| Steve Jones wrote: | BTW, Stefan, this code in Makefile does not work on Solaris
OSTYPE = $(shell uname)
.
.
.
ifeq ($(OSTYPE),solaris)
At least, not on our solaris systems. 'uname' returns SunOS. |
Ok, what about adding:
ifeq ($(OSTYPE),SunOS)
OSTYPE=solaris
endif |
|
1687
|
Mon Feb 13 18:22:08 2006 |
| Steve Jones | steve.jones@freescale.com | Question | Other | 2.6.1 | Re: compiling elog 2.6.1 on solaris platform |
| Stefan Ritt wrote: |
| Steve Jones wrote: | BTW, Stefan, this code in Makefile does not work on Solaris
OSTYPE = $(shell uname)
.
.
.
ifeq ($(OSTYPE),solaris)
At least, not on our solaris systems. 'uname' returns SunOS. |
Ok, what about adding:
ifeq ($(OSTYPE),SunOS)
OSTYPE=solaris
endif |
| Steve Jones wrote: |
That would work, but my question is "why is this statement needed at all?" In GNU-land it appears that the make utilities use the canonical names rather than the ones returned by the OS. When I simply comment out this section, the solaris compile works fine. Perhaps it does not on other platforms?
Also, I ran into another snag. The include file "pty.h" does not appear to exist in solaris-land, so I am seeing if there is one made available elsewhere.
|
|
|
1700
|
Mon Feb 20 17:52:06 2006 |
 | Steve Jones | steve.jones@freescale.com | Question | Other | 2.6.1 | Re: compiling elog 2.6.1 on solaris platform |
| Steve Jones wrote: |
| Stefan Ritt wrote: |
| Steve Jones wrote: | BTW, Stefan, this code in Makefile does not work on Solaris
OSTYPE = $(shell uname)
.
.
.
ifeq ($(OSTYPE),solaris)
At least, not on our solaris systems. 'uname' returns SunOS. |
Ok, what about adding:
ifeq ($(OSTYPE),SunOS)
OSTYPE=solaris
endif |
| Steve Jones wrote: |
That would work, but my question is "why is this statement needed at all?" In GNU-land it appears that the make utilities use the canonical names rather than the ones returned by the OS. When I simply comment out this section, the solaris compile works fine. Perhaps it does not on other platforms?
Also, I ran into another snag. The include file "pty.h" does not appear to exist in solaris-land, so I am seeing if there is one made available elsewhere.
|
|
In working with Stefan changes were made so that the latest release should once again cross-compile fine, and Makefile also works under Solaris. Great job Stefan! |
|
68597
|
Fri Apr 7 12:16:24 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 3.1.1 | Re: command line and apache+ldap authentication | Hi, the elog command line client does not know anything about Apache authentication, therefore the authentication with the elog username/password fails. As an alternative to the command line client you can use the "curl" utility (available under Linux). This tools has the "-u" flag, which works with Apache. The tricky thing is now to "emulate" your browser submitting an entry. You can do
$ curl -u <username>:<password> -F cmd=Submit -F Author=CURL -F Text="This is the CURL text" http://<your host>:8080/<logbook>
(of course your attributes might be different than "Author"). If you have a multiline text body, you can read that from a file (in this case "file.txt"):
$ curl -u <username>:<password> -F cmd=Submit -F Author=CURL -F Text="@file.txt" http://<your host>:8080/<logbook>
When I wrote "elog" orginiallly (199x?), "curl" was not available or at least I didn't know of. Right now it almoste completely can replace the elog tool.
Stefan |
|
69882
|
Fri Jul 18 22:42:02 2025 |
 | Harry Martin | harrymartin772@gmail.com | Bug report | Linux | 3.1.5 | Re: collapse does not seem to work as expected | I should add that this does not happen in every logbook. I'm looking into what the distinction is that causes this in certain logbooks and not in others.
| Harry Martin wrote: |
|
When I click on "collapse," even several times, I still see all the replies in each thread rather than just one entry representing each entire thread.
I am running elogd 3.1.5 on devuan chimaera (bullseye) which I built from source. I had the same results with 3.1.4 and 3.1.3.
I tried to disable the quick filter just to see if that impacted the behavior, but it didn't.
If there are any other tests I can use to narrow the problem, please suggest them. Without a working collapse feature, I cannot get a quick birdseye view of, say, all open threads.
|
|
|
69883
|
Fri Jul 18 23:10:33 2025 |
| Harry Martin | harrymartin772@gmail.com | Bug report | Linux | 3.1.5 | Re: collapse does not seem to work as expected | Figured it out: I had "Sort Attributes" set on the logbooks that were failing to collapse correctly. At least, I think that is the distinction.
I think I can live with "Sort Attributes" disabled; I don't recall why I chose to set the "Sort Attributes" in the first place. But I still think this is an issue.
| Harry Martin wrote: |
|
I should add that this does not happen in every logbook. I'm looking into what the distinction is that causes this in certain logbooks and not in others.
| Harry Martin wrote: |
|
When I click on "collapse," even several times, I still see all the replies in each thread rather than just one entry representing each entire thread.
I am running elogd 3.1.5 on devuan chimaera (bullseye) which I built from source. I had the same results with 3.1.4 and 3.1.3.
I tried to disable the quick filter just to see if that impacted the behavior, but it didn't.
If there are any other tests I can use to narrow the problem, please suggest them. Without a working collapse feature, I cannot get a quick birdseye view of, say, all open threads.
|
|
|
|
69884
|
Sat Jul 19 00:02:45 2025 |
| Harry Martin | harrymartin772@gmail.com | Bug report | Linux | 3.1.5 | Re: collapse does not seem to work as expected | I also notice that collapse does not work properly if I have anything selected in the quick filter.
| Harry Martin wrote: |
|
Figured it out: I had "Sort Attributes" set on the logbooks that were failing to collapse correctly. At least, I think that is the distinction.
I think I can live with "Sort Attributes" disabled; I don't recall why I chose to set the "Sort Attributes" in the first place. But I still think this is an issue.
| Harry Martin wrote: |
|
I should add that this does not happen in every logbook. I'm looking into what the distinction is that causes this in certain logbooks and not in others.
| Harry Martin wrote: |
|
When I click on "collapse," even several times, I still see all the replies in each thread rather than just one entry representing each entire thread.
I am running elogd 3.1.5 on devuan chimaera (bullseye) which I built from source. I had the same results with 3.1.4 and 3.1.3.
I tried to disable the quick filter just to see if that impacted the behavior, but it didn't.
If there are any other tests I can use to narrow the problem, please suggest them. Without a working collapse feature, I cannot get a quick birdseye view of, say, all open threads.
|
|
|
|
|
69891
|
Mon Aug 18 03:14:51 2025 |
| Harry Martin | harrymartin772@gmail.com | Bug report | Linux | 3.1.5 | Re: collapse does not seem to work as expected | I am not sure if either "Sort Attributes" or the Quick Filter are the main issue, though they could be. I have implemented a work-around for now, but it really would be nice if this worked as expected. Or perhaps someone can provide an example of a logbook with working "collapse" functionality. Thank you for this nifty program; everything else aside, this tool helps keep my work in order.
| Harry Martin wrote: |
|
I also notice that collapse does not work properly if I have anything selected in the quick filter.
| Harry Martin wrote: |
|
Figured it out: I had "Sort Attributes" set on the logbooks that were failing to collapse correctly. At least, I think that is the distinction.
I think I can live with "Sort Attributes" disabled; I don't recall why I chose to set the "Sort Attributes" in the first place. But I still think this is an issue.
| Harry Martin wrote: |
|
I should add that this does not happen in every logbook. I'm looking into what the distinction is that causes this in certain logbooks and not in others.
| Harry Martin wrote: |
|
When I click on "collapse," even several times, I still see all the replies in each thread rather than just one entry representing each entire thread.
I am running elogd 3.1.5 on devuan chimaera (bullseye) which I built from source. I had the same results with 3.1.4 and 3.1.3.
I tried to disable the quick filter just to see if that impacted the behavior, but it didn't.
If there are any other tests I can use to narrow the problem, please suggest them. Without a working collapse feature, I cannot get a quick birdseye view of, say, all open threads.
|
|
|
|
|
|