World: r3wp

Have you restarted Cheyenne fully after the changes in httpd.cfg?

I kill the old session with kill -9 and start the new after that

You should stop Cheyenne completly, remove the %.rsp-sessions file 
found in Cheyenne working folder, then restart it.

ls -lR | grep sessions

reveals no such file

Try with ls -laR | grep sessions while Cheyenne is fully stopped.

It's a file starting with a dot (= hidden file), so -lR is not enough 
to list it. Also, it exists only when Cheyenne is not running.

where is the worker-libs block supposed to be located?

GLOBALS section of %httpd.cfg

that seemed to be it. now I'm back to this morning's crash when clicking 
bug entries in the database.

ok, missing table...

The upgrading script should have created all required tables.

it did not. there was a large number of errors, since there were 
no checks if the tables were actually existing or not and I couldn't 
tell whether the upgrade script actually finished.

As I said, the script is for v0.9.6, for your v0.9.8, you should 
have checked manually which tables are already created. You should 
then comment the lines in the upgrade script to match your configuration.

I'm doing each part manually now.

the rss.gif image is missing from the img/ directory.

Thanks, I'm adding it to the online archive.

When logging in this line fails:

if sess/prefs/my-filter [sess/query: copy sess/prefs/my-filter]

The content of SESS/PREFS is:


[version 1 tickets-color-mode line tickets-alt-color #EEE default-project 
1]


I suppose this was meant to be stored in the database, but would 
a better check on this not be:


if select sess/prefs 'my-filter [sess/query: copy sess/prefs/my-filter]

?

I don't see anything about filters in the upgrade script.

Looking into that issue...

It should work okay with v0.9.12. It might be caused by an obsolete 
session object. You should follow the %.rsp-sessions suppression 
process once again.

Hmm, wait, I need to check the database content, it seems that the 
PREFS table might contain obsolete data that are not processed by 
the upgrade script.

Yes, I checked the db content and it contains the block I posted 
above.

You should delete the content of PREFS table, CureCode will recreate 
correct new data if no PREFS record is found:

    DELETE FROM prefs

(make a backup before)

I have test it locally, it should fix your upgrading issue.

ok, that works now.

now when logging in, I get a "redirection trapped" error, but I can 
then proceed to the correct URL via a link below the message.

hmm.. that was either caused by debug/on or my lastpass plugin

Redirection trapped

 is a debug feature, not an error. If debug mode is activated, it 
 produces a intermediary page for HTTP redirection, you have a chance 
 to examine request and session before the redirection is done.

ah, ok. good.

I have upgraded the install script in v0.9.12 archive to handle the 
mysql-protocol.r installation.

my curecode seems to be running OK now.

Glad to hear that. :-)

Does the CureCode currently work for you?

works for me

Strange, I am getting "page unavailable"

Aha, now it finally worked

This is annoying. I do not know why, but in Chrome, I am de facto 
unable to log in to CC. Do you have any idea, what may be the culprit?

Works for me using Chrome

I usually have to wait, until Chrome tells the page is currently 
unavailable

and a different browser is okay?

In IE it seems to work in a snappy way

I don't have issues in Chrome.

It works from here with Chrome too. It might be an internal Chrome 
prefetching or DNS caching issue.

internal Chrome prefetching

 - looks more like postfetching taking into account how sluggish it 
 is

Way back when I reported that I was getting an error with the head.rsp 
file. Well, after being on a fix it binge, I decided to take a look 
at what was going on. It turns out that there were multiple instances 
of Cheyenne running. I am not referring to the multiple instances 
on normally sees but from another build altogether. I still don't 
know where that is getting launched from (I checked the startup and 
all the services etc in msconfig) but by kludging it and renaming 
the build I didn't want, it fixed the issue.

The domain issue.cc has expired since yesterday and is no more reachable. 
It seems I've missed something when transferring it to another registrar, 
so it might be unavailable for one or two more days.

Domain issue.cc is up again.

Perfect, doc.

Domain issue.cc is down again, it seems that the configuration wasn't 
completed after the transfert. I've fixed the config options so it 
should be back online in 24 hours max.