117440 2006-01-02 05:27 0000 2.1_pre2 DISTDIR symlinking breaks cvs svn fetch 2006-02-21 16:40:53 0000 1 1 1 Unclassified Portage Development Core - Configuration 2.1 All Linux RESOLVED FIXED InSVN, REGRESSION P2 critical --- 115839 1 a@gaydenko.com dev-portage@gentoo.org boneyfrog@gmail.com darktama@iinet.net.au dirtyepic@gentoo.org emilbeinroth@gmx.net ferringb@gmail.com hanno@gentoo.org soul@nerdshack.com a@gaydenko.com 2006-01-02 05:27:12 0000 Unfortunately, I can not specify which concrete syncing caused this problem. The problem is: all xxx-cvs.ebuild and xxx-svn.ebuild files fetch/update repositories to/in PORTAGE_TMPDIR instead of DISTDIR. You see, a fetching the whole repo tree discredits repo idea at all. I have not found anything cvs/svn-src dirs specific in 'man make.conf'. portage-2.1_pre3-r1 is in use. darktama@iinet.net.au 2006-01-02 16:46:16 0000 This appears to be an issue specific to portage-2.1_pre3-r1, if I reinstall portage-2.1_pre2 cvs ebuilds (specifically, x11-libs/evas) works correctly. I've worked around the issue by adding these to my make.conf: ECVS_TOP_DIR="/usr/portage/distfiles/cvs-src" ESVN_STORE_DIR="/usr/portage/distfiles/svn-src" Expected behaviour (<=portage-2.1_pre2): * Fetching CVS module e17/libs/evas into /usr/portage/distfiles/cvs-src ... Behaviour with portage-2.1_pre3-r1: * Fetching CVS module e17/libs/evas into /var/tmp/portage/evas-9999/distdir/cvs-src ... vapier@gentoo.org 2006-01-02 18:36:41 0000 *** Bug 117526 has been marked as a duplicate of this bug. *** ferringb@gmail.com 2006-01-04 13:37:33 0000 *** Bug 117784 has been marked as a duplicate of this bug. *** ferringb@gmail.com 2006-01-04 13:38:45 0000 Suggested from ciaran is addition of another var that holds the actual distdir, and modify eclasses in question to use that directory. Would work, although I'd like solar's input on any outstanding perm/security issues with our existing cvs/svn handling- that and any suggestions of improvements we should do since the opportunity exists now. zmedico@gentoo.org 2006-01-04 16:30:41 0000 Perhaps for an ugly interim hack, the eclasses can be modified to use `portageq envvar DISTDIR`. :) solar@gentoo.org 2006-01-05 09:54:57 0000 (In reply to comment #4) > Suggested from ciaran is addition of another var that holds the actual distdir, > and modify eclasses in question to use that directory. Would work, although > I'd like solar's input on any outstanding perm/security issues with our > existing cvs/svn handling- that and any suggestions of improvements we should > do since the opportunity exists now. Well even with the change to making cvs/svn/live ebuilds save files to another dir other than $DISTDIR wont solve the real problem of any user in the portage group can gain uid 0 pretty easy. The default /var/tmp/portage itself is a big apart of the risk due to the ../ being 2777 (pick any of the RPATH bugs for a perfect example) and users & devs alike doing stuff like rm -rf /var/tmp/portage Now for the DISTDIR handling in general. I'm kinda opposed to distdir mangling as it invalidates perfectly valid existing scripts that do stuff like post merge distdir cleanups. Another var would solve that but then poof we just added quite a bit of complexity to every existing script. So whats the real gain of DISTDIR= symlinking? Does it need to be enabled for every EBUILD_PHASE or was it's goal to solve a specific problem with a specific phase? zmedico@gentoo.org 2006-01-06 10:55:41 0000 Created an attachment (id=76363) 2.1_pre3-distdir-revert.patch If you urgently need to use the cvs/svn eclasses, this well revert the "magic" distdir behavior. It backs out the relevant hunk from here: http://sources.gentoo.org/viewcvs.py/portage/main/trunk/pym/portage.py?r1=2469&r2=2474 ferringb@gmail.com 2006-01-06 23:12:50 0000 > Now for the DISTDIR handling in general. I'm kinda opposed to distdir mangling > as it invalidates perfectly valid existing scripts that do stuff like post > merge distdir cleanups. Another var would solve that but then poof we just > added quite a bit of complexity to every existing script. Not worried about breaking your script; design wise, your post distfile cleansing should occur in a different manner. > So whats the real gain of DISTDIR= symlinking? Does it need to be enabled for > every EBUILD_PHASE or was it's goal to solve a specific problem with a > specific phase? Gain is there is no unstated access to DISTDIR by ebuilds. Does a number on restrict="fetch" packages where devs forget to list a file in SRC_URI; does the same for normal packages, also. It also lays the ground work for multiple distdirs, although that's minor. Exempting cvs/svn reasons, not going to revert this change without further args against it- the QA benefit outweigh breaking some custom trickery (sorry :/ ) solar@gentoo.org 2006-01-07 08:40:27 0000 Brian, Simply saying "it should occur in a different manner" is not enough nor a good way to work with others on the team. This should remain a REGRESSION blocking any releases till such time as an alt variable is provided when needing to access the real DISTDIR= ferringb@gmail.com 2006-01-07 15:14:50 0000 It *is* a regression, see the keywords. No stable release till it's fixed, meanwhile the 2.1 releases are developmental releases- bugs do occur. Not going to leave it broke, it will be fixed so just relax. Right now the nasty var hack works, but I'd rather avoid that so I'm digging around for other stuff. ferringb@gmail.com 2006-01-07 16:15:54 0000 Created an attachment (id=76492) fixup.patch Apply this manually for testing please, it adds PORTAGE_ACTUAL_DISTDIR var setting to portage. already modified the eclasses in question to use this var if available, so it should revert the regression. a@gaydenko.com 2006-01-08 08:36:34 0000 > Apply this manually for testing please, it adds PORTAGE_ACTUAL_DISTDIR var > setting to portage. I'm not portage developer. What must I test? OK, I can patch 'portage.py' file. And ... what? Must I modify 'make.conf'? xxx-svn/xxx-cvs ebuilds? I'm ready, but I don't know what to do :-) robert.kruus@utoronto.ca 2006-01-09 08:42:03 0000 seems to work here. just have to mke sure those svn/cvs ebuilds/eclasses now use the PORTAGE_ACTUAL_DISTDIR where required harmgeerts@home.nl 2006-01-09 18:36:34 0000 works for me as well. @Andrew: The cvs/svn ebuild you want to merge should contain a line similar to this: ECVS_TOP_DIR="${DISTDIR}/cvs-src/${PN}" If it doesn't then add it yourself, then replace the DISTDIR variable like this: ECVS_TOP_DIR="${PORTAGE_ACTUAL_DISTDIR}/cvs-src/${PN}" ferringb@gmail.com 2006-01-09 18:57:31 0000 ECVS_TOP_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/cvs-src/" ^^^ use that instead. ECVS_TOP_DIR doesn't specify the PN iirc, plus the var substitution I tagged in there is compatible both with older portages and with portages that have the symlinking in use. All in all, only 4 mods in the tree for this- people shouldn't have to duplicate it themselves, but if they need to, raid from subversion.eclass and/or cvs.eclass for example of how to do it. commited, meanwhile. a@gaydenko.com 2006-01-10 00:29:17 0000 (In reply to comment #15) > ECVS_TOP_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/cvs-src/" > ^^^ use that instead. I have tried to replace ECVS_TOP_DIR="${DISTDIR}/cvs-src" string with this one: ECVS_TOP_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/cvs-src/" Nevertheless, I have got: >>> checksums files ;-) files/digest-pcb-cvs-0.3 >>> Unpacking source... * Fetching CVS module pcb into /wrk/tmp/portage/portage/pcb-cvs-0.3/distdir/cvs-src/ ... I have DISTDIR="/x/portage/distfiles" PORTAGE_TMPDIR="/wrk/tmp/portage" in my make.conf file. Have I missed something? Must I reopen the issue? Must I supply some additional info? ferringb@gmail.com 2006-01-10 01:46:00 0000 (In reply to comment #16) > string with this one: > ECVS_TOP_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/cvs-src/" > > Nevertheless, I have got: > * Fetching CVS module pcb into > /wrk/tmp/portage/portage/pcb-cvs-0.3/distdir/cvs-src/ ... Assuming you're not running with the patch ;) a@gaydenko.com 2006-01-10 02:48:17 0000 (In reply to comment #17) > Assuming you're not running with the patch ;) You are right. I was not waked up completely :-) With the patch I was able to do a work with one of my '-cvs' ebuild. Thanks! emilbeinroth@gmx.net 2006-01-12 10:43:52 0000 ${PORTAGE_ACTUAL_DISTDIR:-${DISTDIR}} would be the correct syntax. emilbeinroth@gmx.net 2006-01-12 14:10:07 0000 I blame solar winds for my last comment. Sorry about that .. zmedico@gentoo.org 2006-02-21 16:40:53 0000 *** Bug 123644 has been marked as a duplicate of this bug. *** 76363 2006-01-06 10:55 0000 2.1_pre3-distdir-revert.patch 2.1_pre3-distdir-revert.patch text/plain SW5kZXg6IHBvcnRhZ2UtMi4xX3ByZTMtcjEvcHltL3BvcnRhZ2UucHkKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g cG9ydGFnZS0yLjFfcHJlMy1yMS5vcmlnL3B5bS9wb3J0YWdlLnB5CisrKyBwb3J0YWdlLTIuMV9w cmUzLXIxL3B5bS9wb3J0YWdlLnB5CkBAIC0yODAyLDMxICsyODAyLDYgQEAgZGVmIGRvZWJ1aWxk KG15ZWJ1aWxkLG15ZG8sbXlyb290LG15c2V0dAogCWlmIG5lZWRfZGlzdGZpbGVzIGFuZCBub3Qg ZmV0Y2goZmV0Y2htZSwgbXlzZXR0aW5ncywgbGlzdG9ubHk9bGlzdG9ubHksIGZldGNob25seT1m ZXRjaG9ubHkpOgogCQlyZXR1cm4gMQogCi0JIyBpbmVmZmljaWVudC4gIGltcHJvdmUgdGhpcyBs b2dpYyB2aWEgbWFraW5nIGFjdGlvbm1hcCBlYXNpbHkgc2VhcmNoYWJsZSB0byBzZWUgaWYgd2Un cmUgaW4gdGhlIGNoYWluIG9mIHdoYXQKLQkjIHdpbGwgYmUgZXhlY3V0ZWQsIGVpdGhlciB0aGF0 IG9yIGZvcmNlZCBOIGRvZWJ1aWxkIGNhbGxzIGluc3RlYWQgb2YgYSBzaW5nbGUgc2V0IG9mIHBo YXNlIGNhbGxzLgotCWlmIChteWRvIG5vdCBpbiAoInNldHVwIiwgImNsZWFuIiwgInBvc3RpbnN0 IiwgInByZWluc3QiLCAicHJlcm0iLCAiZmV0Y2giLCAiZGlnZXN0IiwgIm1hbmlmZXN0IikgYW5k IAotCQkibm9hdXRvIiBub3QgaW4gZmVhdHVyZXMpIG9yIG15ZG8gPT0gInVucGFjayI6Ci0JCW9y aWdfZGlzdGRpciA9IG15c2V0dGluZ3NbIkRJU1RESVIiXQotCQllZHBhdGggPSBteXNldHRpbmdz WyJESVNURElSIl0gPSBvcy5wYXRoLmpvaW4obXlzZXR0aW5nc1siUE9SVEFHRV9CVUlMRERJUiJd LCAiZGlzdGRpciIpCi0JCWlmIG9zLnBhdGguZXhpc3RzKGVkcGF0aCk6Ci0JCQl0cnk6Ci0JCQkJ aWYgb3MucGF0aC5pc2RpcihlZHBhdGgpIGFuZCBub3Qgb3MucGF0aC5pc2xpbmsoZWRwYXRoKToK LQkJCQkJc2h1dGlsLnJtdHJlZShlZHBhdGgpCi0JCQkJZWxzZToKLQkJCQkJb3MudW5saW5rKGVk cGF0aCkKLQkJCWV4Y2VwdCBPU0Vycm9yOgotCQkJCXByaW50ICIhISEgRmFpbGVkIHJlc2V0aW5n IGVidWlsZCBkaXN0ZGlyIHBhdGgsICIgKyBlZHBhdGgKLQkJCQlyYWlzZQotCQlvcy5ta2Rpcihl ZHBhdGgpCi0JCW9zLmNob3duKGVkcGF0aCwgLTEsIHBvcnRhZ2VfZ2lkKQotCQlvcy5jaG1vZChl ZHBhdGgsIDA3NzUpCi0JCXRyeToKLQkJCWZvciBmaWxlIGluIGFhbGlzdDoKLQkJCQlvcy5zeW1s aW5rKG9zLnBhdGguam9pbihvcmlnX2Rpc3RkaXIsIGZpbGUpLCBvcy5wYXRoLmpvaW4oZWRwYXRo LCBmaWxlKSkKLQkJZXhjZXB0IE9TRXJyb3I6Ci0JCQlwcmludCAiISEhIEZhaWxlZCBzeW1saW5r aW5nIGluICclcycgdG8gZWJ1aWxkIGRpc3RkaXIiICUgZmlsZQotCQkJcmFpc2UKLQogCWlmIG15 ZG89PSJmZXRjaCIgYW5kIGxpc3Rvbmx5OgogCQlyZXR1cm4gMAogCg== 76492 2006-01-07 16:15 0000 fixup.patch patch text/plain SW5kZXg6IHBvcnRhZ2UucHkKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gcG9ydGFnZS5weQkocmV2aXNpb24gMjU0 MikKKysrIHBvcnRhZ2UucHkJKHJldmlzaW9uIDI1NDMpCkBAIC0yODA5LDcgKzI4MDksOCBAQAog CSMgd2lsbCBiZSBleGVjdXRlZCwgZWl0aGVyIHRoYXQgb3IgZm9yY2VkIE4gZG9lYnVpbGQgY2Fs bHMgaW5zdGVhZCBvZiBhIHNpbmdsZSBzZXQgb2YgcGhhc2UgY2FsbHMuCiAJaWYgKG15ZG8gbm90 IGluICgic2V0dXAiLCAiY2xlYW4iLCAicG9zdGluc3QiLCAicHJlaW5zdCIsICJwcmVybSIsICJm ZXRjaCIsICJkaWdlc3QiLCAibWFuaWZlc3QiKSBhbmQgCiAJCSJub2F1dG8iIG5vdCBpbiBmZWF0 dXJlcykgb3IgbXlkbyA9PSAidW5wYWNrIjoKLQkJb3JpZ19kaXN0ZGlyID0gbXlzZXR0aW5nc1si RElTVERJUiJdCisJCSMgcmVtb3ZlIFBPUlRBR0VfQUNUVUFMX0RJU1RESVIgb25jZSBjdnMvc3Zu IGlzIHN1cHBvcnRlZCB2aWEgU1JDX1VSSQorCQlteXNldHRpbmdzWyJQT1JUQUdFX0FDVFVBTF9E SVNURElSIl0gPSBvcmlnX2Rpc3RkaXIgPSBteXNldHRpbmdzWyJESVNURElSIl0KIAkJZWRwYXRo ID0gbXlzZXR0aW5nc1siRElTVERJUiJdID0gb3MucGF0aC5qb2luKG15c2V0dGluZ3NbIlBPUlRB R0VfQlVJTERESVIiXSwgImRpc3RkaXIiKQogCQlpZiBvcy5wYXRoLmV4aXN0cyhlZHBhdGgpOgog CQkJdHJ5Ogo=