On Fri, 20 Jun 2014 15:55:05 +0200 (CEST)
Erik Braun wrote:
> In short, the computer stalls on some file operations when stacking an
> aufs directory above an OpenAFS directory, no matter, if the OpenAFS
> is writable or not.
>
> The author of aufs sees the problem (specifically from his point o
Hi,
I discussed this topic almost 3 months ago on the aufs mailing list, but
had at this time other things to do. Now I can look at this problem again,
since it is still present in Debian Testing with OpenAFS 1.6.9 and the
shipped Linux kernel 3.14.7.
In short, the computer stalls on some fi
Uploaded. Thanks for the report and the quick reaction.
Stephan
On 2014-06-20, at 12:55, Stephen Quinney wrote:
> Apologies, that was caused by me manually regenerating the repodata for EL5
> from an EL6 machine without using checksum option. I'll fix the repodata now,
> it will take a little
Apologies, that was caused by me manually regenerating the repodata for EL5
from an EL6 machine without using checksum option. I'll fix the repodata
now, it will take a little while before it reaches the public repository.
Stephen
On 20 June 2014 11:35, Andreas Lehner wrote:
> Hello.
>
> The O
Hello.
The OpenAFS 1.6.9 binaries provided for Red Hat Enterprise Linux 5[0]
carry a defective repomd.xml[1]. EL5 provides versions of yum and
hashing libraries that are incapable of computing sha256 checksums.
Previous OpenAFS releases were created using sha checksums[2].
The packages seem to ha