We've had an issue with rsync users not recieving updated cache entries because the metadata changed without the size or the timestamp of the cache entry changing. The reason is that portage always stamps the metadata with the timestamp of the ebuild. My proposed solution is to make portage automatically bump the timestamp of the ebuild inside portdbapi.aux_get() whenever an changed eclass triggers a regen. I could do this via an external script on osprey, but it doesn't seem like it would hurt to include this in portage. The timestamp of the ebuild could be updated to match that of the most recently modified eclass that it inherits from.
I think I'll just make this an external script, since the problem is only applicable to the current cache format.
Brian Harring has given me a nice idea for a short term solution. I can modify the cache generation system so that it toggles the EAPI back and forth between 0 and empty whenever a cache entry is updated. That will change the size of the cache entry by one byte and force rsync to consider the change.
(In reply to comment #2) > toggles the EAPI back and forth between 0 and empty I've realized that this doesn't really solve the problem. The file size does not change only because of a coincidence (a rare one). Even with the EAPI hack, it is still possible for such a coincidence to occur.
*** Bug 143289 has been marked as a duplicate of this bug. ***
This has just broken vmware stuff because of SRC_URI part being set in vmware.eclass. Would be nice to get a workaround at least.
Hehehe, had a mid-air collision with Jakub, I was just about to say: I just hit the same problem with the vmware-server/workstation/player/modules ebuilds. They all use a variable in their SRC_URI, which is set and changed in an inherited eclass. I bumped all the manifests/digests, but after syncing the metadata didn't agree with the ebuild, and portage checked for digests from files mentioned in the metadata cache (which weren't necessary anymore). For now, I've just gone and added a pointless comment to all the ebuilds and re-manifested them. Is there anything simpler I could do to solve the problem, like just touching the ebuilds or something?
(In reply to comment #6) > Is there anything simpler I could do to solve the problem, > like just touching the ebuilds or something? That's the best you can do from your end. The timestamp has to change on the staging box and that normally only when a change in file content triggers a cvs update.
Pardon me, but is there a solution for this bug? I'd like to update app-emulation/vmware-server-1.0.1.29996 but can't: >>> Emerging (4 of 6) app-emulation/vmware-server-1.0.1.29996 to / * VMware-server-1.0.1-29996.tar.gz MD5 ;-) ... [ ok ] * VMware-server-1.0.1-29996.tar.gz RMD160 ;-) ... [ ok ] * VMware-server-1.0.1-29996.tar.gz SHA1 ;-) ... [ ok ] * VMware-server-1.0.1-29996.tar.gz SHA256 ;-) ... [ ok ] * VMware-server-1.0.1-29996.tar.gz size ;-) ... [ ok ] * vmware-server-perl-fixed-rpath-libs.tar.bz2 MD5 ;-) ... [ ok ] * vmware-server-perl-fixed-rpath-libs.tar.bz2 RMD160 ;-) ... [ ok ] * vmware-server-perl-fixed-rpath-libs.tar.bz2 SHA1 ;-) ... [ ok ] * vmware-server-perl-fixed-rpath-libs.tar.bz2 SHA256 ;-) ... [ ok ] * vmware-server-perl-fixed-rpath-libs.tar.bz2 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking VMware-server-1.0.1-29996.tar.gz ;-) ... [ ok ] * checking vmware-any-any-update101.tar.gz ;-) ... [ !! ] !!! Missing digest for 'vmware-any-any-update101.tar.gz' How to get around this problem?
(In reply to comment #8) > Pardon me, but is there a solution for this bug? I'd like to update > app-emulation/vmware-server-1.0.1.29996 but can't: > !!! Missing digest for 'vmware-any-any-update101.tar.gz' It should be vmware-any-any-update103.tar.gz. I've touched the ebuild on the server in order to correct that. Seeing how badly this problem affects vmware.eclass, I'll script a workaround ASAP to touch the ebuilds automatically when eclass changes like this are detected.
First off, thanks very much for working on this Zac, I do appreciate it... 5:) Secondly, it's a bit odd, since that ebuild didn't exist until both the overlay and the main tree were using update103, so it's all a bit strange, but luckily I've got a perfect test case for you when you think the patch is ready, since they've brought out update104...
I've got a script in place that should solve this for now. It keeps a database file size, timestamp, and md5 sum for each cache entry and touches the ebuild and cache entry if the md5 changes while the other two remain the same. Please test.
Right, sorry that took so long. We just pushed the vmware-any-any-update to 104. All the relevant digests have been updated, so hopefully people will get recalculated metadata when the rsync servers catch up to the cvs server. I'll post mention here of any bugs we may encounter (hopefully none!). Thanks again Zac... 5:)
My logs indicate that the following ebuilds were automatically touched: app-emulation/vmware-player-1.0.1.19317-r4 app-emulation/vmware-modules-1.0.0.11 app-emulation/vmware-server-1.0.0.28343 app-emulation/vmware-modules-1.0.0.13 app-emulation/vmware-workstation-4.5.3.19414-r4 app-emulation/vmware-modules-1.0.0.8 app-emulation/vmware-server-1.0.1.29996 app-emulation/vmware-workstation-5.5.1.19175-r4 app-emulation/vmware-workstation-3.2.1.2242-r11
Looks spot on! 5:) Is this good enough to be a permanent fix, or should we keep the bug open looking for something more?
This will be fine as a permanent fix. Eventually, the cache format will be fixed so that it doesn't require this hack.
Question - I still have the error saying that the digest for update101 can't be found. I'm seeing it on three different systems. I've also tried touching the ebuild, the eclass file, removing stuff from /var/edb/cache/... Nothing helps. Example: sly fetched file: VMware-server-1.0.1-29996.tar.gz SHA1 ;-) >>> Previously fetched file: VMware-server-1.0.1-29996.tar.gz SHA256 ;-) >>> Previously fetched file: VMware-server-1.0.1-29996.tar.gz size ;-) >>> Previously fetched file: vmware-server-perl-fixed-rpath-libs.tar.bz2 MD5 ;-) >>> Previously fetched file: vmware-server-perl-fixed-rpath-libs.tar.bz2 RMD160 ;-) >>> Previously fetched file: vmware-server-perl-fixed-rpath-libs.tar.bz2 SHA1 ;-) >>> Previously fetched file: vmware-server-perl-fixed-rpath-libs.tar.bz2 SHA256 ;-) >>> Previously fetched file: vmware-server-perl-fixed-rpath-libs.tar.bz2 size ;-) >>> checking ebuild checksums ;-) >>> checking auxfile checksums ;-) >>> checking miscfile checksums ;-) >>> checking VMware-server-1.0.1-29996.tar.gz ;-) >>> checking vmware-any-any-update101.tar.gz !!! Missing digest for 'vmware-any-any-update101.tar.gz' !!! Fetch for /usr/portage/app-emulation/vmware-server/vmware-server-1.0.1.29996.ebuild failed, continuing... !!! Some fetch errors were encountered. Please see above for details. emerge --info output if you're interested: Portage 2.1-r2 (default-linux/x86/2006.1, gcc-3.4.6, glibc-2.4-r3, 2.6.17-suspend2-r4 i686) ================================================================= System uname: 2.6.17-suspend2-r4 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 2.20GHz Gentoo Base System version 1.12.4 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] 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-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i586 -mno-tls-direct-seg-refs -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /home/httpd /lib/modules /usr/NX/etc /usr/NX/home /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=i586 -mno-tls-direct-seg-refs -pipe" DISTDIR="/export/home1/portage/distfiles" FEATURES="autoconfig buildpkg ccache distcc distlocks metadata-transfer sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://mirror.datapipe.net/gentoo http://open-systems.ufl.edu/mirrors/gentoo http://mirrors.tds.net/gentoo" LANG="en_US" LINGUAS="en" PKGDIR="/export/home1/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/export/home1/portage/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="x86 3dfx X acpi alsa apache2 asf berkdb bitmap-fonts bzip2 cli crypt cups dbus dlloader dri dvd eds encode firefox flac font-server foomaticdb fortran gd gdbm gif gimp gimpprint gnome gnutls gpm gps gstreamer gtk gtk2 ieee1394 imagemagick ipv6 isdnlog java jce jpeg libg++ libwww mbox mbrola mikmod milter mmx motif mozsvg mp3 mpeg mpeg2 ncurses nls no-htdocs nptl nptlonly nsplugin nvidia nxclient ogg opengl pam pcre pda perl plugin png ppds pppd python qt4 quicktime rdesktop readline reflection sdl server session shape softmmu spell spl sse ssl tcpd tetex tiff truetype truetype-fonts trusted type1-fonts udev unicode usb userlocales vnc vorbis win32codecs xfs xml xorg xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_en userland_GNU video_cards_nvidia video_cards_vesa video_cards_fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS Thanks!
(In reply to comment #16) > Question - I still have the error saying that the digest for update101 can't be > found. I'm seeing it on three different systems. I've also tried touching the > ebuild, the eclass file, removing stuff from /var/edb/cache/... Nothing helps. Do you have an old copy of vmware.eclass in your overlay? Your problem is unrelated to this bug. If necessary, file a new bug.
Perfect. I'd forgotten to remove the overlay files. Thank you!
Did the fix for this break again? Current vmware-modules is attempting to use vmware-any-any-update109.tar.gz according to the metadata/cache entry, but the ebuild is trying to find update112.
oh wait, this might be a new problem. it looks like vmware-modules now is pulling in the ANY-ANY version from vmware.eclass. I'm assuming that the script that was updating the cache entries was intended to handle changes to the ebuild itself and not necessarily eclass changes right? If I'm being totally stupid and ignorant here, feel free to correct me.
I'm not yet sure what went wrong with vmware-modules. See bug 187129.
This is solvable via using a custom cache module for the rsync generation that does the following: 1) track the mtime/size of the existing cache entry 2) generate the new entry. if the size/mtime is the same, append a space to one of the fields (DESCRIPTION gets my vote). 3) serialize per the norm. Technically tihs still has the potential to have a size/mtime collision on the users box (rather then on the rsync nodes themselves)- this is solvable via keeping a history of the mtime/size for an ebuild, bumping the size forward as needs be till the mtime changes (thus resetting the size down to the original size). That's a bit heinous, but should cover every potential angle.
@zac: see any issues w/ your current solution, or the fallback of the heinous bit proposed above? In other words, is this finally dead (thus no longer an arguing point for DIGESTS addition)?
(In reply to comment #23) > @zac: see any issues w/ your current solution, or the fallback of the heinous > bit proposed above? In other words, is this finally dead (thus no longer an > arguing point for DIGESTS addition)? Your suggested solution is more practical that the existing one so I think I'll go ahead and implement it. I still want to add the DIGESTS data though, since the existing timestamp validation mechanism is too fragile.
(In reply to comment #24) > Your suggested solution is more practical that the existing one so I think I'll > go ahead and implement it. I started on the patch but then I started thinking about potential timestamp/size collisions that could occur over a series of months (and users possibly being affected depending on the last time they synced). The current timestamp bumping approach is not vulnerable to this problem, so I guess I'll keep the existing approach.
This bug is handled by the egencache --rsync option.
