upgraded to 1.12.13 earlier today and since then, my gentoo cvs commits have been randomly hanging ... then when i kill them and run `cvs up` to see what needs repairing, i get these weird '.new.<file i was trying to commit>' files that cvs usually cleans up while running `cvs up` ... cant seem to narrow it down at all, but i hit this: $ cvs-1.12.13 -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bitpim \ co -P bitpim .... U bitpim/unixpkg/getallwxlibs U bitpim/unixpkg/rpathfixup cvs checkout: inflate: invalid code lengths set cvs [checkout aborted]: reading from server: Input/output error $ cd bitpim $ cvs-1.12.13 up ? winpkg/.new.unicows.d cvs update: inflate: invalid code lengths set cvs [update aborted]: reading from server: Input/output error $ cvs-1.12.12 up ? winpkg/.new.unicows.d U winpkg/unicows.dll $ cvs-1.12.12 up $ rm -r winpkg $ cvs-1.12.13 up cvs update: inflate: invalid code lengths set cvs [update aborted]: reading from server: Input/output error $ cvs-1.12.13 up ? winpkg/.new.unicows.d cvs-1.12.13 update: inflate: invalid code lengths set cvs-1.12.13 [update aborted]: reading from server: Input/output error $ cvs-1.12.12 up ? winpkg/.new.unicows.d U winpkg/unicows.dll $ cvs-1.12.12 up $ the other thing that i cant really show here is that 1.12.13 tends to sit there for a while before erroring while 1.12.12 runs through quickly Portage 2.1_pre5-r2 (default-linux/amd64/2005.1, gcc-4.0.2, glibc-2.3.6-r2, 2.6.14.6-grsec x86_64) ================================================================= System uname: 2.6.14.6-grsec x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.6.14 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-lang/python: 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10, 2.16-r1, 2.16.1, 2.16.1-r2, 2.16.90.0.3, 2.16.91.0.1, 2.16.91.0.2, 2.16.91.0.3, 2.16.91.0.4, 2.16.91.0.5, 2.16.91.0.6 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r4 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=k8 -pipe -D_FORTIFY_SOURCE=1 -Wimplicit-function-declaration" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -march=k8 -pipe -D_FORTIFY_SOURCE=1" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests autoconfig ccache cvs distlocks noauto noinfo sandbox sfperms sign splitdebug" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1 -Wl,-z,relro" LINGUAS="en" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://gentoo/gentoo-portage" USE="amd64 X a52 aac aalib acl adns aio alsa asf audiofile berkdb bitmap-fonts bzip2 cairo cddb cdparanoia crypt cups dba directfb divx4linux dts dvd dvdr dvdread emboss encode esd exif fbcon ffmpeg flac flash foomaticdb gd gif glitz glut gphoto2 gpm gtk gtk2 imap imlib ipv6 jbig joystick jpeg jpeg2k libcaca libedit lzo lzw lzw-tiff mad maildir matroska mikmod mime mng modplug mp3 mpeg mplayer multislot ncurses nls nptl nptlonly nvidia offensive ogg oggvorbis openal opengl pcre pdflib perl pic png python quicktime readline real samba sdl sndfile spell ssl subtitles svg tcltk tcpd tga theora threads tiff truetype truetype-fonts type1-fonts usb userlocales vcd vorbis wmf xanim xine xinerama xml xml2 xmms xpm xrandr xv xvid xvmc zlib elibc_glibc kernel_linux linguas_en userland_GNU video_cards_nvidia" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL
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.
