New upstream version. Copying existing ebuild for 1.12 is sufficient. Fun fact: rawdog barfs if you happen to use a NFS home directory, since the fcntl.lockf() calls in persister.py always seem to fail. The symptom of this is you get a zero-length state file, which rawdog reports is corrupted, i.e. An error occurred while reading state from <home>/.rawdog/state. This usually means the file is corrupt, and removing it will fix the problem. Workaround is to comment the fcntl.lockf() calls out. Fix: Write a temporary file (with a different name) in the same directory, flush it, close it, rename it over the original (DJB-style). After looking through the code, I think removing the lockf calls is enough since the locking looks pretty worthless (file is only locked when reading and not writing, except for initial creation). Maybe do this in the unpack: sed -i -e 's/fcntl.lockf(/#fcntl.lockf/' rawdoglib/persister.py Error reporting leaves a lot to be desired in this scenario. Same behavior in 1.12, so this should not be a blocker for 1.14.
I guess the locking's not completely worthless, though still a problem with NFS, but that's not likely to affect too many people.
2.0 is now out upstream. The 1.12 ebuild still works fine. Should I make a new bug for this?
rawdog-2.4 upstream version has been available for at least a month now. Rewrote summary to reflect portage reorganization. The rawdog-1.12 ebuild in portage works fine for 2.4 by renaming. I've been using it for about a month.
Confirming that a rename does work for 2.4
Confirming also that it works fine here by renaming the ebuild file.
This ain't web-apps.
*** Bug 98049 has been marked as a duplicate of this bug. ***
In Portage. Thanks for info.
