Quoting Daniel Baumann (2019-02-28 10:28:19) > > You could also test if disabling the apt sandboxing feature fixes the > > problem for you by adding the following option to mmdebstrap: > > > > --aptopt='APT::Sandbox::User "root"' > so technically this isn't a bug in mmdebstrap, may I suggest to put a note > with this e.g. into the manpage or README.Debian or something like that?
How about the following instead: When apt is run in a way such that it cannot do sandboxing, then it just prints a warning but otherwise continues without a non-zero exit code. We can do the same in mmdebstrap. So if mmdebstrap is run in a directory that the _apt user does not have access to, then lets just disable apt sandboxing and print a warning message about that. This way, mmdebstrap will still finish successfully without this unintuitive error message. With this commit: https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/920877fa2ad26a3ee04f9554cf7ec7d468e5df2a One should now see the following: I: chroot architecture amd64 is equal to the host's architecture I: Reading sources.list from standard input... touch: cannot touch '/tmp/debian-unstable/var/lib/apt/lists/partial/dummy': Permission denied E: Sub-process touch returned an error code (1) W: Download is performed unsandboxed as root as file /tmp/debian-unstable/var/lib/apt/lists/partial/dummy couldn't be accessed by user _apt I: running apt-get update... I: downloading packages with apt... I: extracting archives... I: installing packages... I: cleaning package lists and apt cache... Thanks! cheers, josch
signature.asc
Description: signature
