| Summary: | dev-util/catalyst fails on live CVS ebuilds | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Jonas Bernoulli <jonas> |
| Component: | Catalyst | Assignee: | Gentoo Catalyst Developers <catalyst> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Jonas Bernoulli
2008-01-26 14:33:15 UTC
*** Bug 207562 has been marked as a duplicate of this bug. *** This is a known problem, but nobody has ever really looked into it. Catalyst is primarily a tool for building Gentoo releases, and we never use CVS ebuilds in releases. This means our motivation for looking into this is minimal. If someone can track down the issue and provide a patch, I'm sure we'd be more than happy to include it. So you are saying that this is probably a catalyst bug? I will try to track this down once I have time. Sorry about the double post. What Andrew was saying was that nobody has looked into it. It could be a catalyst bug or it could be a bug in the ebuild. We don't know. We've seen it with other ebuilds, too, so it's probably not an ebuild bug. However, it's possible that it's a combination of an eclass and a catalyst bug. I have looked into this a little and found a workaround. By inserting `cvs -q -f -z1 -d ":pserver:anonymous:@cvs.savannah.gnu.org:/sources/emacs" login' (after moving the code that creates $CVS_PASSFILE to the top) at various places in cvs_fetch(), I learned, that changing the working directory to /usr/portage/distfiles/cvs-src triggers the error. Before doing so the login command succeeds. This directory however does exist. I also checked if the bug still exists if I prevent catalyst from binding /usr/portage/distfiles, which it does. So basically I don't know more than before: CVS thinks that the directory does not exist despite the fact that it does. But I found an easy workaround. In stageN-chroot.sh I added: export ECVS_TOP_DIR=/tmp to work around the problem. I hope that you will include this workaround in catalyst, though you would probably set that envvar somewhere else. We typically don't like workarounds, especially ones as "specific" as that one. If you can find the root cause, we'll do what we can to actually fix it. Seems that this one is a CVS bug. I get this problem when trying to use CVS from an automounted NFS4 directory. $ pwd /home/wine_builder/cvs/LinuxPackaging $ cvs -n up cvs [update aborted]: cannot get working directory: No such file or directory $ df . Filesystem 1K-blocks Used Available Use% Mounted on - 975425536 836082688 139342848 86% /net/gw/Projects Updating summary, since the problem seems not to be Emacs specific. (Also Emacs has moved from CVS to Bazaar. Does the bug still occur with app-editors/emacs-vcs, i.e. bzr.eclass?) (In reply to comment #9) > (Also Emacs has moved from CVS to Bazaar. Does the bug still occur with > app-editors/emacs-vcs, i.e. bzr.eclass?) I no longer use catalyst so I won't be able to test it. However it is extremely unlikely that this bug also occurs with bzr. (As has been said this probably is cvs bug. Even if it is an ebuild (or catalyst) bug this should not affect the behaviour of bzr in any way.) So with regards to Emacs this bug is indeed resolved. (In reply to comment #10) > So with regards to Emacs this bug is indeed resolved. Emacs team is out of here. AFAIK this is a bug on cvs, it fails on bind-mounted directories... Is there anything for catalyst to "fix" here? From Raúl's comment, perhaps this should be assigned to the cvs maintainers? No replies, so closing. |
