* 025_all_samba-3.0.x-pdb-mysql.patch ... * Failed Patch: 025_all_samba-3.0.x-pdb-mysql.patch ! That patch uses an absolute path starting at /var, so for those of us that have PORTAGE_TMPDIR somewhere else, it fails. The patch just needs to be fixed to use the same path as the other patches.
same here.
Created attachment 70714 [details] 025_all_samba-3.0.x-pdb-mysql.patch-28816.out Fails to patch here as well. Attaching patch output.
fixed. thanks. just remove the /usr/portage/distfile/samba-3-gentoo-0.3.9* patchset and re-'emerge sync': the new digest line is MD5 864fcda25aec603fcc7849f79a7c77a2 samba-3-gentoo-0.3.9.tar.bz2 16783 Old (wrong) one is: MD5 c8e73e9cf44f443ae1694ab9c88cb8c7 samba-3-gentoo-0.3.9.tar.bz2 16803
*** Bug 109353 has been marked as a duplicate of this bug. ***
Please bump the version of the tarball so we stop getting bad digests. Its the much more sane solution.
A version bump was my first idea, but (provided the original patch was of course wrong :-) ): 1) (minor) this issue occurs mostly (if not only) to experienced users, who know how to customize their enviroment (and so have the skill to edit portage tree and/or to delete a stale download) 2) (insignificant) a symbolic link from </var/tmp/portage> to <whatever> can be a workaround 3) (the main reason) forcing a revision bump (both in patchset and in ebuild, of course) would have caused many users to upgrade (and recompile) without any benefit. If default vs custom settings users are in a (personally estimated) ratio of 10:1, this would end in about 50-60 users (== standard configs) affected Given the short amount of time involved (9-13 hours, considering mirrors sync time also), I simply chose to trust in the skills of gentoo users :-) Flame me if the affected user base is larger than I thought, or if I'm clamorously missing something
Argh! gentoo.mirros.pair.com still has the old samba-3-gentoo.. patch. Had to take out my mirrors line in make.conf.
(In reply to comment #6) > 3) (the main reason) forcing a revision bump (both in patchset and in ebuild, of > course) would have caused many users to upgrade (and recompile) without any > benefit. No revision bump is necessary. Just bump the patchset and change the version in the ebuild. Everyone that it installed for already is fine, its the people that are having problems upgrading that you need to worry about now. > Given the short amount of time involved (9-13 hours, considering mirrors sync > time also), I simply chose to trust in the skills of gentoo users :-) Looks like it still hasn't been updated on mirrors, so I think this is something that still needs to be resolved. > Flame me if the affected user base is larger than I thought, or if I'm > clamorously missing something I believe its pretty standard procedure to just bump the version of the patchset when you need to make a change to it, isntead of hoping all the mirrors will get the new version.
> Looks like it still hasn't been updated on mirrors, so I think this > is something that still needs to be resolved. I'm really curious about (external) mirrors policy: why (sometimes) are they so slow to synchronize? Anyway, I've commited the new patchset version.