David Kalnischkies <david@kalnischkies.de> (2015-11-28): > Mhhhhhh. apt is run as root (as we don't reach this codepath with uid != > 0), but it has all the groups of kibi and a setgroups is silently > ignored… wtf… Hmmm, there's fakeroot in the middle! | ifneq ($(shell id -u),0) | ROOTCMD ?= fakeroot | endif | | # Useful command sequences | define submake | $(ROOTCMD) $(MAKE) --no-print-directory -j1 | endef which probably explains why copying/pasting the command line worked, as opposed to running make and submakes, the last ones being under fakeroot? > The code is if someone wants to look: > https://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/fileutl.cc#n2264 > I will go to bed now, maybe I have an epiphany tomorrow. > (or manage to reproduce this for a start) > > > > While I've been experimenting with adding/removing myself from the said > > groups, I'm noticed this a few times, without being able to figure out > > what exactly causes this… > > | W: No sandbox user '_apt' on the system, can not drop privileges > > > > In which case, going back to apt.git and "sudo debi -u" to reinstall all > > packages I've built seems to fix the issue. > > As mentioned briefly schroot copies users & groups from your host > system, so if your host system has no _apt user, the _apt user in your > schroot will "disappear" next time it is copied over. Ah, right. That explains why running adduser/deluser from within/outside the chroot made little difference, given the culprit was my leaving and re-entering the chroot session… I'm not sure how buildds are set up, and whether _apt will stick there (not really a reasonable hour to go look it up though); there are different flavours/profiles in the sbuild and schroot worlds anyway, so hopefully that's going to “just work”. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature