Hmm, not sure. I'm not really a Python guy, just packaged this.

Out of curiosity, have you tried the new 1.1.1 release by any chance (it is available in F-11)? Does that work better?

I just recompiled the F11 1.1.1 release for F10 and it works. Now the problem is: you have to merge your old configuration into the new config file: they are not 100% compatible.
By the way: this does not really fix the F10 distro...
Thanks for the suggestion

If we release 1.1.1 as an update to F-10, would that be OK for you?

Personnally: Yes! But I fear people not aware of this problem will get in trouble by a simple "yum update" installing a release that is not 100%compatible with their current configuration file. Whether to do it or not is under your own responsibility: As a reference, clamav people did not do it, but mediawiki people did!
The best solution would be to fix the current F10 version, but like you, I'm not a Python guy so I can't help you for that. Sorry.

Looking at the error, I'm guessing this may have something to do with permission to write to whatever turns out to be the target tarball directory (most likely directory is read only for apache user).

I'm wondering if we need to modify the code to generate the tarball in /var/spool/viewvc, like we do for enscript temp files?

Could I ask you a favour to strace httpd when the failure occurs? I just want to see two things:

1. Where does that tarball get written out to (i.e. look for open calls)?
2. Does the call to open() or write() fail with some kind of permissions issue?

You can run Apache with "httpd -X" which will then give you a single process, instead of many. Just attach yourself to it with strace -f -p `pgrep httpd` and you should see that.

I did what you ask for and, I'm afraid, it seems there is no temporary directory and/or file: tar format is generated by python procedures and compression is achieved directly to the standard output via a pipe + fork to a gzip parallel process.
The write() fails with EPIPE, not EPERM.
I will try to investigate more from the strace output. If you want it, I can send it to you by e-mail: for confidentiality reasons (there may be auth info and/or private data in it), I will not attach it here: just ask if you want so.

OK, thanks for that info.

You are not running SELinux on this machine, right?

No, it is disabled.

OK, thanks. Back to the drawing board.

I found something strange in the strace output:

[pid 25568] read(18,  <unfinished ...>
 .
 . (other pids)
 .
[pid 25567] write(1, "\37\213\10\0\0\0\0\0\0\3\354\375{w\0347\2228\210\316\277\355OQ+\317\375\215\275#S\225\211"..., 16384 <unfinished ...>
[pid 25568] <... read resumed> "\37\213\10\0\0\0\0\0\0\3\354\375{w\0347\2228\210\316\277\355OQ+\317\375\215\275#S\225\211"..., 1024) = 1024
[pid 25568] close(18)
 .
 .
 .
[pid 25568] write(2, "Exception in thread Thread-1:\nTraceback (most recent call last):\n  File \"/usr/lib/python2.5/threading.py\", line 486, in __bootstrap_inner\n    self.run()\n  File \"/usr/lib/python2.5/site-packages/viewvc/lib/popen.py\", line 318, in run\n    self.destfile.write(s)\n  File \"/usr/lib/python2.5/site-packages/viewvc/lib/sapi.py\", line 101, in write\n    self.server.write(s)\n  File \"/usr/lib/python2.5/site-packages/viewvc/lib/sapi.py\", line 83, in __getattr__\n    return getattr(self.self(), key)\n  File \"/usr/lib/python2.5/site-packages/viewvc/lib/sapi.py\", line 80, in self\n    return self.__dict__['servers'][thread.get_ident()]\nKeyError: -1212183664\n\n"..., 647) = 647
[pid 31390] _exit(0)                    = ?


pid 25568 executes procedure run in class _copy (/usr/lib/python2.5/site-packages/viewvc/lib/popen.py, line 312)

  def run(self):
    try:
      while 1:
        s = os.read(self.srcfd, 1024)
        if not s:
          break
        self.destfile.write(s)
    finally:
      os.close(self.srcfd)

This means there is an exception in this thread at write time. It should be read as:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.5/threading.py", line 486, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.5/site-packages/viewvc/lib/popen.py", line 318, in run    self.destfile.write(s)
  File "/usr/lib/python2.5/site-packages/viewvc/lib/sapi.py", line 101, in write
    self.server.write(s)
  File "/usr/lib/python2.5/site-packages/viewvc/lib/sapi.py", line 83, in __getattr__
    return getattr(self.self(), key)
  File "/usr/lib/python2.5/site-packages/viewvc/lib/sapi.py", line 80, in self
    return self.__dict__['servers'][thread.get_ident()]
KeyError: -1212183664

Then the thread stops, causing the gzip process exit by EPIPE, in turn causing an EPIPE error in the viewvc writing thread.
We do not see this error in the normal output because it is in a parallel (probably /dev/null-redirected?) thread. However it seems to be the cause of the displayed error.

I hope it helps

Thanks for this. Unfortunately way beyond my Python, so I think I'm going to toss that upstream to see what they make of it.

Created attachment 355717 [details]
Dirty patch to fix this bug

OK, although I'm not used to Python, I've understand what happens and managed to get it working with a dirty python-newbie patch !!!
Module sapi.py provides classes for different kind of servers (CGI, ASP and ModPython). In our case, ModPython is used and it's derived from a ThreadedServer class that registers the Server instances associated with a particular thread.
In popen.py, a _copy class creates a thread that is NOT a server by itself, and did NOT register its Server instance. This would be OK for a non-ThreadedServer derived server class (providing we could use threads in a non-ThreadedServer ;-), but bad for our case because the ThreadedServer instance to use is determined in some procedures via the thread ident as key to the above mentioned registry. No registering --> no key --> Exception
The patch causes the _copy instance thread to register to its destination file's server, only if registering methods exist...
Probably very dirty, but it works !
Please note this code is totally suppressed in version 1.1.1

That patch is infinitely better than any I could come up with (which is none), so I may package it up and put it up for testing. Thanks for going in so much depth for this!

viewvc-1.0.8-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/viewvc-1.0.8-2.fc10

viewvc-1.0.8-2.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update viewvc'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8455

viewvc-1.0.9-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/viewvc-1.0.9-1.fc10

viewvc-1.0.9-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.