When a new release is built at the stage1 phase /var/cache/edb is created with perms 755. Repoman uses metadata.dtd in the cache directory for commits, it fetches it into distfiles and moves it into the cache dir and it fails there since the dir isn't group writable (portage) with this being done as a simple and mortal user. Thus 2007.0 stages aren't good out of the box for devs.
As I mentioned on IRC, from a quick scan the relevant code in portage hasn't changed in the last 12 months, so don't know why it worked before (it sets the permissions to 755).
The 0755 that's in config._init_dirs() will allow earlier permissions to bleed through if they're not explicitly masked. So, the user can `chmod g +w /var/cache/edb` and the bit will not be removed by portage. Looking at portage.py from portage-2.0.54, it used to set 0775 permissions on CACHE_PATH, so that's one place the bit would have been set automatically in the past that it isn't now. Perhaps repoman should simply use the metadata.dtd directly from $DISTDIR. Copying it to /var/cache/edb doesn't really make a difference since it doesn't lock the file while it's using it anyway.
In svn r6562 I've fixed it to use metadata.dtd directly from $DISTDIR.
This has been released in 2.1.2.8.
I/O error : Attempt to load network entity http://www.gentoo.org/dtd/metadata.dtd whenever I run repoman; gets repeated for every ebuild it checks.
(In reply to comment #5) > I/O error : Attempt to load network entity > http://www.gentoo.org/dtd/metadata.dtd Sorry about that. I had the following entry in /etc/xml/catalog which prevented me from receiving that message: <rewriteURI uriStartString="http://www.gentoo.org/dtd/" rewritePrefix="/usr/portage/metadata/dtd/"/> It's fixed in svn r6632 so that message is hidden like before unless there's a real error from xmllint.
This has been released in 2.1.2.9.
