Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Updating world, sun-jdk-1.5 failed complaining due to digest verification failing. Checked the ebuild, and found what looked like a changelog for php more than an ebuild: # ChangeLog for dev-php5/pecl-apc # Copyright 1999-2008 Gentoo Foundation; Distributed under the GPL v2 # $Header: /var/cvsroot/gentoo-x86/dev-php5/pecl-apc/ChangeLog,v 1.39 2008/03/28 19:19:42 hoffie Exp $ 28 Mar 2008; Jakub Moc <jakub@gentoo.org> Reproducible: Always Steps to Reproduce: 1.emerge -Davut world 2. 3. Actual Results: >>> Verifying ebuild Manifests... !!! Digest verification failed: !!! /usr/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild !!! Reason: Failed on RMD160 verification !!! Got: 751637964edd458f00c9c72de8f5375eabaf9004 !!! Expected: c7268656bf1adccafde5dd9c1104c5a12905b1dc Expected Results: Emerged Synced from: rsync://128.61.111.9/gentoo-portage Portage 2.1.4.4 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.7-r1, 2.6.24-gentoo-r2 x86_64) ================================================================= System uname: 2.6.24-gentoo-r2 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ Timestamp of tree: Sat, 29 Mar 2008 08:15:04 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r4, 2.5.1-r5 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.24 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/init.d /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache collision-protect distlocks metadata-transfer nostrip parallel-fetch sandbox sfperms splitdebug strict unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ http://gentoo.osuosl.org/ ftp://gentoo.ccccom.com http://gentoo.ccccom.com http://mirrors. tds.net/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LINGUAS="en ja zh_TW zh_CN ko" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl alsa amd64 anthy apache2 asf audiofile avahi avi bash-completion batch berkdb bidi bitmap-fonts bluetooth cdr cjk cli cracklib crypt cups daap dbus divx4linux dri dts dvd dvdr dvdread emacs encode faad fam fastcgi ffmpeg flac foomaticdb fortran freetype ftp fuse gdbm gif gimpprint gnutls gpm gstreamer gtk gtk2 gtkhtml guile hal httpd iconv imagemagick immqt-bc ipod ipv6 isdnlog ivman jack java jce jpeg kde kerberos kqemu lame latex lcms ldap libclamav live mad matroska midi mime mmx mng mozilla mozsvg mp3 mpeg mudflap musepack mysql ncurses nls nptl nptlonly nsplugin nvidia oav offensive ogg opengl openmp oss pam pcre pdf perl php png ppds pppd python qt qt3 qt4 quicktime readline reflection ruby samba scanner sdl session speex spl sse sse2 ssl stream svg swig tcltk tcpd theora threads truetype truetype-fonts type1-fonts unicode usb utempter v41 vcd videos visualization vlm vorbis wavpack wma wmf wxwindows x264 xchatdccserver xchattext xine xml xorg xosd xprint xvid yp zeroconf zlib" ALSA_CARDS="atiixp" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en ja zh_TW zh_CN ko" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #0) > Updating world, sun-jdk-1.5 failed complaining due to digest verification > failing. Checked the ebuild, and found what looked like a changelog for php > more than an ebuild: > > # ChangeLog for dev-php5/pecl-apc > # Copyright 1999-2008 Gentoo Foundation; Distributed under the GPL v2 > # $Header: /var/cvsroot/gentoo-x86/dev-php5/pecl-apc/ChangeLog,v 1.39 The ChangeLog file is also wrong.
I did a temp fix of re-digesting this ebuild, which is a bad hack at best. Adding self to status emails so I can rebuild this soon as it's fixed
Infra, this is a problem with the master mirror, probably. Several hours later I'm still not getting sane files. sources.gentoo.org is not accessible btw.
Please set it to critical, due to the fact that also other ebuilds are affected. emerge "=dev-java/sun-jdk-1.4*" -f Calculating dependencies \!!! Digest verification failed: !!! /usr/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild !!! Reason: Failed on RMD160 verification !!! Got: 751637964edd458f00c9c72de8f5375eabaf9004 !!! Expected: c7268656bf1adccafde5dd9c1104c5a12905b1dc ... done! >>> Emerging (1 of 1) dev-java/sun-jdk-1.4.2.17 to / !!! Digest verification failed: !!! /usr/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild !!! Reason: Failed on RMD160 verification !!! Got: 751637964edd458f00c9c72de8f5375eabaf9004 !!! Expected: c7268656bf1adccafde5dd9c1104c5a12905b1dc !!! Fetch for /usr/portage/dev-java/sun-jdk/sun-jdk-1.4.2.17.ebuild failed, continuing... !!! Some fetch errors were encountered. Please see above for details. dev-java/sun-jdk-1.4.2.17 Workaround: remove EBUILD line from Manifest remove /usr/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild
The sun-jdk-1.5.0.15-r1 ebuild seems to be correct on the master mirror (osprey.g.o). I've just synced from one of the normal mirrors (got hawk.g.o) and the ebuild seems to be correct there too. Perhaps only one or a subset of rsync mirrors have gotten corrupted.
Confirmed also on rsync://216.176.132.235/gentoo-portage
I traced the source. The new rsync1.us(albatross) has gotten a corrupted copy somehow. I'm working on it now.
rsync spewed some errors a while ago into a log, and corrupted the data. The actual filesystem level was fine. I zapped the bad files and they went right now. This is probably a case that the MetaManifest GLEP I need to finish writing would have caught.
Still facing this problem, using rsync.europe.gentoo.org...
I want to confirm the bug at 10:55 UTC, using SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" in make.conf. How much time is it until mirrors sync? Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-gentoo-r8 i686) ================================================================= System uname: 2.6.23-gentoo-r8 i686 Pentium III (Coppermine) Timestamp of tree: Sun, 30 Mar 2008 10:15:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /usr/share/emacs/21.4/lisp/pcvs-parse.el /usr/share/mplayer/font" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distcc distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://gentoo.inf.elte.hu/ http://ftp.lug.ro/gentoo/ http://ftp.roedu.net/pub/mirrors/gentoo.org/ http://ftp.romnet.org/gentoo/ http://mirrors.evolva.ro/gentoo/ " MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/erlay /usr/portage/local/layman/java-overlay /home/cipi/portage_overlay" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE=... (not relevant)
rsync seems to be screwing it up. albatross gentoo-portage # md5sum /data/gentoo-portage/portage-tmpfs/gentoo-portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild /data/gentoo-portage/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild d6c0497d19a49a51ca64fcc8ec36acd4 /data/gentoo-portage/portage-tmpfs/gentoo-portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild 0a20f9e8391de7e02fbe61849eff4628 /data/gentoo-portage/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild albatross gentoo-portage # ls -la /data/gentoo-portage/portage-tmpfs/gentoo-portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild /data/gentoo-portage/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild -rw-r--r-- 1 root root 4471 Mar 28 23:35 /data/gentoo-portage/portage-tmpfs/gentoo-portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild -rw-r--r-- 1 root root 4471 Mar 28 23:35 /data/gentoo-portage/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild I'm going to add --checksum to the rsync call.
Better full output, only these 3 files appear to be getting it wrong. albatross gentoo-portage # md5sum {portage-tmpfs/gentoo-portage,portage}/{dev-java/sun-jdk/ChangeLog,dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild,dev-java/sun-jre-bin/ChangeLog} 96595dac9a25b1170ddfc0e23dfb7aad portage-tmpfs/gentoo-portage/dev-java/sun-jdk/ChangeLog d6c0497d19a49a51ca64fcc8ec36acd4 portage-tmpfs/gentoo-portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild 769ef2f7b1445f712a00d5f7f34dcdf1 portage-tmpfs/gentoo-portage/dev-java/sun-jre-bin/ChangeLog 86a231e1464e26abe5cee8b748e53185 portage/dev-java/sun-jdk/ChangeLog 0a20f9e8391de7e02fbe61849eff4628 portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild aa62f89bba1dfae67ac07bc863565983 portage/dev-java/sun-jre-bin/ChangeLog albatross gentoo-portage # ls -la {portage-tmpfs/gentoo-portage,portage}/{dev-java/sun-jdk/ChangeLog,dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild,dev-java/sun-jre-bin/ChangeLog} -rw-r--r-- 1 root root 44483 Mar 28 23:35 portage-tmpfs/gentoo-portage/dev-java/sun-jdk/ChangeLog -rw-r--r-- 1 root root 4471 Mar 28 23:35 portage-tmpfs/gentoo-portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild -rw-r--r-- 1 root root 22710 Mar 28 23:35 portage-tmpfs/gentoo-portage/dev-java/sun-jre-bin/ChangeLog -rw-r--r-- 1 root root 44483 Mar 28 23:35 portage/dev-java/sun-jdk/ChangeLog -rw-r--r-- 1 root root 4471 Mar 28 23:35 portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild -rw-r--r-- 1 root root 22710 Mar 28 23:35 portage/dev-java/sun-jre-bin/ChangeLog
*** Bug 215441 has been marked as a duplicate of this bug. ***
Ok, this should be fixed properly now. It was a bit of a duzi.
(In reply to comment #14) > Ok, this should be fixed properly now. It was a bit of a duzi. rsyncing at 21:10 with rsync.europe.gentoo.org gives still th php-changelog-crap. As far as I remember, the mirrors are synced every 30min, am I right? So there still must be something wrong in syncing mirrors... ervin
I have too this problem. Are from Europe. A update not solve the Problem.
(In reply to comment #14) > Ok, this should be fixed properly now. It was a bit of a duzi. > As of 2008-03-30 20:19:47 UTC, still no luck. been a good 3 hours, but still same error. Note, I rsync to namerica, not europe.
just checked the mirrors just like Arvid Norlander (bug 215441, comment 2) [nils@nils-desktop:/tmp/jdk]md5sum * (03-30 15:29) d6c0497d19a49a51ca64fcc8ec36acd4 128.10.252.13 d6c0497d19a49a51ca64fcc8ec36acd4 128.104.70.17 d6c0497d19a49a51ca64fcc8ec36acd4 128.213.5.35 d6c0497d19a49a51ca64fcc8ec36acd4 128.61.111.9 d6c0497d19a49a51ca64fcc8ec36acd4 129.110.111.9 d6c0497d19a49a51ca64fcc8ec36acd4 132.207.4.160 d6c0497d19a49a51ca64fcc8ec36acd4 134.153.48.2 d6c0497d19a49a51ca64fcc8ec36acd4 141.219.155.230 d6c0497d19a49a51ca64fcc8ec36acd4 150.135.81.231 d6c0497d19a49a51ca64fcc8ec36acd4 156.56.247.193 d6c0497d19a49a51ca64fcc8ec36acd4 206.75.218.53 2a7ed74d36a073f85b1054f4ff73530a 208.209.50.18 d6c0497d19a49a51ca64fcc8ec36acd4 209.221.142.124 d6c0497d19a49a51ca64fcc8ec36acd4 209.59.138.21 d6c0497d19a49a51ca64fcc8ec36acd4 216.165.129.134 d6c0497d19a49a51ca64fcc8ec36acd4 216.176.132.235 d6c0497d19a49a51ca64fcc8ec36acd4 216.194.64.133 "d6c0497d19a49a51ca64fcc8ec36acd4 is the md5sum of the broken file" seems that every mirror but one has the broken file (note, this is just a subset), and the one without corruption has an outdated version. Please reopen bug
Please also note that rsync doesnt notice that these ebuilds are corrupt, even when syncing to a good mirror. I had to remove the folders containing said ebuilds, then sync to a good mirror to get everything working.
I can categorically state that the master mirror is sending out the correct files, so now I'm wondering if we have found a bug in rsync - specifically in how it uses the mtime and the filesize to detect changes. vapier: you're the rsync guy. WTF is going on? Here's the copy as it is on the master: -rw-r--r-- 1 root root 44483 Mar 28 23:35 /data/gentoo-portage/portage-tmpfs/gentoo-portage/dev-java/sun-jdk/ChangeLog 86a231e1464e26abe5cee8b748e53185 /data/gentoo-portage/portage-tmpfs/gentoo-portage/dev-java/sun-jdk/ChangeLog -rw-r--r-- 1 root root 4471 Mar 28 23:35 /data/gentoo-portage/portage-tmpfs/gentoo-portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild 0a20f9e8391de7e02fbe61849eff4628 /data/gentoo-portage/portage-tmpfs/gentoo-portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild -rw-r--r-- 1 root root 22710 Mar 28 23:35 /data/gentoo-portage/portage-tmpfs/gentoo-portage/dev-java/sun-jre-bin/ChangeLog aa62f89bba1dfae67ac07bc863565983 /data/gentoo-portage/portage-tmpfs/gentoo-portage/dev-java/sun-jre-bin/ChangeLog -rw-r--r-- 1 root root 44483 Mar 28 23:35 /data/gentoo-portage/portage/dev-java/sun-jdk/ChangeLog 86a231e1464e26abe5cee8b748e53185 /data/gentoo-portage/portage/dev-java/sun-jdk/ChangeLog -rw-r--r-- 1 root root 4471 Mar 28 23:35 /data/gentoo-portage/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild 0a20f9e8391de7e02fbe61849eff4628 /data/gentoo-portage/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild -rw-r--r-- 1 root root 22710 Mar 28 23:35 /data/gentoo-portage/portage/dev-java/sun-jre-bin/ChangeLog aa62f89bba1dfae67ac07bc863565983 /data/gentoo-portage/portage/dev-java/sun-jre-bin/ChangeLog In the meantime, I'm going to force the mtimes to change on the files in CVS.
this is expected rsync behavior. if the mtime and filesize are the same, it assumes the file has not been updated. in a sane system, this assumption is correct. if the rsync mirrors violate this sanity, then it sounds like the rsync mirrors are broken and that needs to be addressed. in fact, this behavior is documented in like the first page of text on the man page. if you want something more in depth, you need to specify the options for it. for example, the -c (compare crc's) is one such option.
If the mtime/filesize are paired for checking, shouldn't simply updating the correct dev-java/sun-jdk-1.5.0.15-r1 with an extra newline at the end cause rsync to pick it up and transfer it to the mirrors?
vapier: it got contents from ANOTHER file that happened to have the same mtime and filesize, but a totally different path. the documentation implies the tuple for verification is (path, mtime, filesize), however it acted as if it was (mtime, filesize).
are you sure it was rsync that introduced the corruption ? assuming it was, it'll be near impossible to deduce the problem without a reproducible test case
vapier: it's masterrsync (osprey) -> rsync1.us (disk) -> rsync1.us (tmpfs-backed reiserfs) -> outside mirrors -> users. The rsync.1.us disk copy was fine, while the tmpfs-backed-reiserfs one was not. Both of them passed fsck, and I re-mkfs'd the tmpfs-backed storage for good measure. However, if you think it's a good idea, I can see about getting all the mirrors running with --checksum for when they fetch from rsync1.us. Either rsync has a bug, or there might be a very remote possibility that there was a kernel issue (we ran into a bug with CONFIG_PAX_EMUTRAMP=y in the kernel, but it only seemed to affect sandbox and caused total sandbox failures so nothing was emergable).
*** Bug 215527 has been marked as a duplicate of this bug. ***
Does it matter that the problem still exists? I removed the dev-java directory hierarchy and then synched again with rsync5.de.gentoo.org. I still get the wrong file.
Problem persists for me too, just synched with SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
Even when all(In reply to comment #22) > If the mtime/filesize are paired for checking, shouldn't simply updating the > correct dev-java/sun-jdk-1.5.0.15-r1 with an extra newline at the end cause > rsync to pick it up and transfer it to the mirrors? > Indeed it would, and that would also fix it at the "end users", unlike just making the mirrors themselves use -c, where the fix still wouldn't get through to the end users.
Just synced with rsync.europe.gentoo.org (SYNC=http://trumpetti.atm.tut.fi/gentoo-portage) and I can confirm that the files are now what they should be. # md5sum /usr/portage/dev-java/sun-jdk/{sun-jdk-1.5.0.15-r1.ebuild,ChangeLog} 4bb9d28710579c7c15bdcc49447214aa /usr/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild 033612e95bb0b3250df44d5286f1f403 /usr/portage/dev-java/sun-jdk/ChangeLog
(In reply to comment #30) > Just synced with rsync.europe.gentoo.org > (SYNC=http://trumpetti.atm.tut.fi/gentoo-portage) and I can confirm that the > files are now what they should be. ACK from another mirror in Germany.
(In reply to comment #31) Just synced with namerica, and the manifests now verify.
(In reply to comment #28) Now working for me as well... giddy ~ # md5sum /usr/portage/dev-java/sun-jdk/{sun-jdk-1.5.0.15-r1.ebuild,ChangeLog} d6c0497d19a49a51ca64fcc8ec36acd4 /usr/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild 96595dac9a25b1170ddfc0e23dfb7aad /usr/portage/dev-java/sun-jdk/ChangeLog giddy ~ # ls -l /var/log/emerge.log -rw-rw---- 1 portage portage 736573 2008-03-31 13:44 /var/log/emerge.log giddy ~ # eix-sync [...] giddy ~ # md5sum /usr/portage/dev-java/sun-jdk/{sun-jdk-1.5.0.15-r1.ebuild,ChangeLog} 4bb9d28710579c7c15bdcc49447214aa /usr/portage/dev-java/sun-jdk/sun-jdk-1.5.0.15-r1.ebuild 033612e95bb0b3250df44d5286f1f403 /usr/portage/dev-java/sun-jdk/ChangeLog giddy ~ # date Mon Mar 31 18:38:45 CEST 2008 Last sync happened to be rsync://88.198.224.205/gentoo-portage.
Robin: i think adding checksum will cause significant overhead on all systems and that's really not desirable going by your description of things, it obviously shouldnt have happened, but without a test case to look at, we're pretty much hosed
we've got the cpu in infra to run with --checksum, so we will (it's already in place and live actually, after this bug cropped up). I'll leave it up to the community rsync mirrors to run it if they want. Closing as NEEDINFO, since there's no easy testcase and we've just avoided it for now.
