Hi Johannes Schauer Marin Rodrigues <jo...@debian.org> writes:
> By default, mmdebstrap does not print the output of the commands it runs. It > does that though when something goes wrong. So if "apt install" fails, then > you > get its output. In your case, you missed a "note" (not even a warning) in the > "apt update" output. You would've seen that if you had run mmdebstrap with the > --verbose option. No. I was running mmdebstrap --verbose, and the note wasn't in the output. I only saw the note when I set up a similar situation in a real arm64 install (no schroot, no mmdebstrap), and tried to "apt update" there. mmdebstrap passing on the note would have helped. > You initially suggested mmdebstrap to drop down to a shell and print a command > for the user to re-run. Lets assume that this were possible (I don't think it > is feasible). In that case, you still would not've known how to proceed or > that > it is the apt pinning that is at fault. > <snip> If a shell was available, you can do lots of quick experiments quickly, and narrow down the problem quickly. I routinely use tools like sysdig to report all system-wide syscalls, and that output is enough to figure out lots of problems. You can use it without the shell too, without reproducing the problem in isolation, but it's harder to interpret the logs. > So given all of this, I don't think your initial suggestion of adding a > facility to drop to a shell and re-run a command in shell would've fixed your > problem. Maybe. Maybe not. Can we agree that the capability to do this in sbuild is extremely useful, at least? I find it extremely valuable. > I have no problem helping you with this and it doesn't bother me but I > also don't see anything that is to be learned from all of this. OK. Hopefully I don't need to bug you many more times. Thanks a lot for the help!
