Happy to report that both invocations of grml-debootstrap and pbuilder / cowbuilder are compatible with mmdebstrap.
Johannes Schauer: > you seem to claim that mmdebstrap does not support the --arch argument. But it > does. It does so by configuring Getopt::Long with auto_abbrev. This means that > a long option like --architectures can also be written with less characters. > It > works on my system. It does not on yours? Also from the man page: > > Long options require a double dash and may be abbreviated to uniqueness. Magic. :) Works for me. :) >> Using a file >> /home/user/Whonix/build_sources/debian_stable_current_clearnet.list >> which contains both, Debian "standard" repository as well as Debian >> security repository. >> >> This is to make use of mmdebstrap excellent security feature to >> bootstrap from two repositories at once. If the APT version in Debian >> "standard" repository had a vulnerability, then the vulnerable version >> would be installed first before vulnerable APT would be used to upgrade >> in a later step from Debian security repository. >> >> "Incompatibility" is perhaps a far stretched term. How do we "teach" >> grml-debootstrap, cowbuilder (or pbuilder?) "use both, Debian "standard" >> repository and Debian security repository when using mmdebstrap"? >> >> It's like "the ecosystem does not take advantage of mmdebstrap" yet. > > Okay, but as far as I can see there is nothing that can be done in mmdebstrap > about this, right? Maybe not. I guess the problem indeed isn't mmdebstrap but how other tools are invoking $DEBOOTSTRAP. Do you think you could contact pbuilder / cowbuilder / grml-debootstrap to see how invocation of debootstrap (single repository) vs mmdebstrap (Debian "standard" repository + Debian security repository) invocation could be sorted out? Not sure how crazy would it be to have mmdebstrap auto inject the Debian security repository? Perhaps keep mmdebstrap as is but have a wrapper mmdebstrap-sec-repo (or so) that injects it? >> Not sure anymore why I added: >> --include=apt,sudo,devscripts,debhelper,strip-nondeterminism,fakeroot,apt-transport-tor,apt-transport-https,python,eatmydata,aptitude,cowdancer >> >> apt-transport-https might be required to support https repositories in >> sources list. > > Yes, old apt versions (1.4.9 and earlier) require that package. It is since a > dummy package. Yay. >> apt-transport-tor might be required to support tor+https and .onion in >> sources list. > > Yes, but mmdebstrap auto-detects tor URLs and adds the package. This behaviour > is also documented in its man page. Magic. :) ##### When mmdebstrap finished, there is still a leftover. /etc/apt/apt.conf.d/99mmdebstrap My apt options are good during build (apt cache etc.) but bad in the final VM image. Should this file be deleted? ##### mmdebstrap fails when /etc/hostname is missing. An empty /etc/hostname works for me. Sometimes it's not wanted to leak any host files into the folder (reproducible builds, privacy, and whatnot). Could you please have mmdebstrap handle non-existing /etc/hostname (and other system files (/etc/host /etc/resolv.conf?) gracefully? ##### minor: >From home folder (in a Qubes Debian VM): ./mmdebstrap --include=apt --variant=buildd --force-check-gpg buster ./test https://deb.debian.org/debian I: The option --force-check-gpg is a no-op. It only exists for compatibility with some debootstrap wrappers. I: automatically chosen mode: unshare I: chroot architecture amd64 is equal to the host's architecture mkdir /home/user/test: Permission denied at ./mmdebstrap line 992. ls -la drwxr-xr-x 2 100000 100000 4096 Sep 15 06:07 test ##### minor: > I: The option --force-check-gpg is a no-op. It only exists for compatibility with some debootstrap wrappers. Not sure that implies insecurity. I know gpg signatures are verified but could confuse others. Perhaps just drop that option from output. Keep it in man page / command line help only. Users / wrappers using --force-check-gpg get what they expect anyhow. No need to notify. Cheers, Patrick
