On Sun, Jul 26, 2015 at 01:56:02PM +0200, Marc Espie wrote: > On Sat, Jul 25, 2015 at 09:02:54PM +0000, Christian Weisgerber wrote: > > On 2015-07-25, Landry Breuil <[email protected]> wrote: > > > > > after fighting a bit with perms (_pbuild needs write access to > > > ${WRKOBJDIR} so either put it in wsrc or or install -d -o _pbuild > > > ${WRKOBJDIR} in the STARTUP script, _pfetch needs write to > > > /usr/ports/distfiles so.. ive put it in wsrc for now) stuff finally > > > started building "fine". Two things: > > > - not easy to fix failures with another user. Is it possible to have > > > _pbuild run umask 002 so that i can share a group with it ? I suppose > > > this could be done in login.conf.. would that be a sensible default ? > > > > Basically you are destroying the separation between users that is > > the point of _pfetch/_pbuild in the first place. > > > > I think the way to solve this is to dive into bsd.port.mk and have > > manual builds use "${SUDO} -u _pbuild" etc. to switch to the same > > user as dpb at the respective stages. > > Unfortunately, this won't quite work. > > *most* of what happens in bsd.port.mk happens as _pbuild. > Specifically, fetch happens as _pfetch. > *parts* of prepare *must* happen as root. > > and some specific targets, such as update-patches, makesum, require the > ports tree user.
Whatever, in the meantime i can still do make WRKOBJDIR=/usr/obj/fuck as my user if i want to fiddle/try to fix a failure. Or use umask 002 locally in login.conf. Thanks for the lengthy e-mail, but i didnt see anything related to the install -m 2755 / chmod g+s failure.. which is affecting "production" builds. Should i read into the lines that this works only in chroot mode ? Landry
