Summary: | cvs-1.12.13 is seriously funked up | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
Component: | [OLD] Development | Assignee: | Maintainers for cvs, and cvs related tools (the version control system) [OBSOLETE] <cvs-utils+obsolete> |
Status: | RESOLVED CANTFIX | ||
Severity: | major | CC: | flameeyes, mmokrejs, polynomial-c, slyfox, walch.martin |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=14840 | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=587140 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | cvs-1.12.13-zlib.patch |
Description
SpanKY
2006-03-02 20:14:17 UTC
spanky: is this limited to cvs.sf.net or does it happen with a lot of other cvs servers as well? eg cvs.g.o? at the top of my original description: upgraded to 1.12.13 earlier today and since then, my gentoo cvs commits have been randomly hanging ... source of bug seems to be cvs's interaction with zlib. Using the internal zlib doesn't produce any improvements. running with -z0 works perfectly fine, using various other -z* levels produce hangs and errors around the compression points. Upstream's cvshome website is down, as are the lists.nongnu.org. pylon: I'm going to mask cvs-1.12.13 for the moment. I also had one hang. But I thought, that the cause was my unsteady net-connection... @robbat2: Thanks for masking PS: cvs.non-gnu.org is just a kind of wrapper-page with some general information. The real successor of cvshome is http://ximbiot.com/cvs/ Upstream says, it's fixed... ...in their CVS, so it will be part of 1.12.14 (see bug http://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=15087). As those bugs where closed already, I didn't saw them before committing a newer cvs-version into portage. I am observing the slowdowns for few weeks as well on my ~x86 machine with 1.12.13. Will try 1.12.13r3 now if I get through the upgrade (currently sys-libs/glibc-2.4-r1 compile breaks for me). Anyway, what I do see here is: $ cvs -t -z9 commit -m "blah" classes.py -> main: Session ID is oUMVrBKUQBzPmdqr -> main loop with CVSROOT=/home/xxx/.cvsroot -> open_connection_to_server (xxx@x.x.x.x:/home/xxx/.cvsroot) -> Starting server: ssh -l xxx x.x.x.x cvs server -> Sending file `classes.py' to server S -> serve_directory (.) S -> dirswitch (., /home/xxx/.cvsroot/xxx) And now the connection stalls. tcpdump tracing shows no traffic between the machines. I have also seen less problems when using -z0 but it still doesn't help always. mmokrejs: did you read this thread before posting? 1.12.13 is deliberately masked because it's broken, and I don't know where you're getting 1.12.13r3, that certainly isn't in the tree. Downgrade to 1.12.12* and you will be fine. Yes, I have read the thread. But it wasn't clear what exactly was causing the slowdowns. So that's why I've posted. Yes, "1.12.13r3" was my typo, I've meant "1.12.12r3". Yes, USE=server" emerge =dev-util/cvs-1.12.12-r3 Created attachment 84319 [details, diff]
cvs-1.12.13-zlib.patch
Ok, I'm testing the zlib patch now, I'll report back soon. Ok, i've just commited 1.12.13-r1, masked with package.mask. It passes my testing, but I want you to test it as well, before I remove it from package.mask. I've added a functional src_test, but it doesn't test this bug. Please test this issue, and report back. a quick test shows it working OK ... cvs-1.12.13.1 is going into the tree shortly, and contains all of upstream's recommended fixes for this. i'll keep it p.mask for a week or two, and then move to ~arch. ok, xnay on the 1.12.13.1. while it passes all of it's own tests file, it does some other weird shit when I try to use it with other CVS servers. CVS 1.12.13* are completely broken, and I'm removing them from the tree entirely now. Maybe 1.12.14 if it ever comes out will be better. (In reply to comment #16) > ok, xnay on the 1.12.13.1. while it passes all of it's own tests file, it > does some other weird shit when I try to use it with other CVS servers. Our bug is really old, but maybe your last observation was due to introduced draconic PGP verification? https://lists.nongnu.org/archive/html/bug-cvs/2007-01/msg00019.html Setting envvar to CVS_VERIFY_CHECKOUTS=warn seemingly makes 'cvs' work chatty, but does the thing. We might switch that default to make 'repoman commit' and friends work by default. |