Hi, Quoting Dima Kogan (2023-05-30 05:34:20) > > Since all hooks have the MMDEBSTRAP_HOOK variable set, whatever is run in > > the > > hook would have access to the type of hook that failed. > > > > The information that would be missing would be *which* hook of a certain > > type > > was the one failing. I do not see a good way to communicate this > > information. > > Ideally, mmdebstrap will tell you which command failed, so the user can > cut/paste the failing command to reproduce the failure. This maybe is > the most important thing to communicate? I might be missing the > subtleties of what you're thinking.
ah I see our main difference might be that I run mmdebstrap mostly from other scripts whereas you are running it interactively and thus you want a shell if something goes wrong. > > Do you know of another software besides sbuild that has a similar interface? > > I'd like to get some more ideas first before I add another interface that > > mmdebstrap would have to support forever. > > I can only thing of sbuild off the top of my head. But mmdebstrap > already has a hook system, so extending that in the way you suggested > above sounds like a self-consistent way to do it. Yes, but every new feature comes at a cost, so I'd like to be very careful about adding more stuff and first check if it can be avoided. > > I'd also like to add that you can already emulate this behaviour by > > running a hook like this: > > > > --customize-hook='chroot "$1" i-might-fail || chroot "$1" bash' > > I would want to add the '|| chroot "$1" bash' to everything mmdebstrap > does: downloading packages, installing them, doing customization hooks, > etc, etc. The above just applies to customization hooks, right? Oh, so you want the interactive shell on other things than failing hooks? You also want that shell when any command run by mmdebstrap failed? > The actual failure I'd like to fix today is a failing "apt update" > trying to talk to my apt-cacher-ng server (for some reason the server > returns 502 only when mmdebstrap tries to talk to it). I don't believe > there's a nice way to debug this with mmdebstrap today, right? I tried > to use --SOMETHING-hook (don't remember what SOMETHING was), but it > wasn't clear what the exact failing command was, so I moved on to > something else. Printing the exact failing command for easy > reproducibility would be important. Maybe there's already a verbosity > level that does this? The commands should be printed if you increase verbosity with --verbose or even with --debug. If the command is not printed, then that is a bug that I will fix. For your specific problem I would first try to take mmdebstrap out of the loop and see if the problem can be replicated with plain apt as well. The man page contains a small shell snippet that does the essential things that mmdebstrap does but without mmdebstrap in the section OPERATION: https://manpages.debian.org/unstable/mmdebstrap/mmdebstrap.1.en.html#OPERATION You could try if that script with your apt-cacher-ng setup produces the same error and then you've already reduced the number of moving parts. Thanks! cheers, josch
signature.asc
Description: signature
