Hi. Currently it's possible to do

  sbuild --anything-failed-commands '%s'

to get an interactive shell in response to any step of the process
failing. This makes it much easier to debug problems. It would be great
if mmdebstrap had a similar function.

I'm currently trying to debug an issue with an apt-cacher-based server
failing when mmdebstrap is pulling from it (but not when anything else
is pulling from it), and that option would make this process much
easier.

Thanks

Hi Dima,

I'm putting Helmut in CC who is in favour of such an option as well and who
might have more ideas.

Quoting Dima Kogan (2023-05-29 18:42:57)

how about an option like this:

Johannes Schauer Marin Rodrigues <josch@debian.org> writes:

I don't care about the exact command, as long as it's documented. This
suggestion sounds reasonable.

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.

Hmmm. The obvious thing to say would be "It doesn't matter; we failed,
so mmdebstrap should just exit regardless". But maybe the hook can fix
whatever the failure was, and if the hook callback succeeds, mmdebstrap
can try again? In my usage of these in sbuild I'm always debugging
failures, so just exiting regardless is the right thing. But maybe
something smarter would be good too.

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.

Yeah. Let's conform to the existing mmdebstrap conventions

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?

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?

Thanks much!

Hi,

Quoting Dima Kogan (2023-05-30 05:34:20)

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.

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.

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 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

Johannes Schauer Marin Rodrigues <josch@debian.org> writes:

I usually run it from scripts too. But if something goes wrong, I re-run
it manually, and having an easy way to get a shell at the failing point
would be nice.

Yessir. A shell where the failure is quickly reproduced makes fixing
problems MUCH faster. That's what sbuild does, and I've used this
countless times.

Good to know. I admittedly haven't spent a ton of time working on it.

I did that. The problem only shows up with mmdebstrap. I doubt it's a
bug in mmdebstrap, but that's the only place I see this.

I can do that. But fixing this hasn't been very high priority for me
today, so I haven't put in the work. I'm just using this as an example
of a case where the --failure-hook option would be useful.

Thanks much.

Hi,

Quoting Dima Kogan (2023-05-30 20:48:59)

let me tell you about another trick. Instead of running


There is a big difference between the commands run by sbuild and the commands
run by mmdebstrap. In sbuild, when your package fails, you start a shell inside
your build chroot, cd into the right directory and run dpkg-buildpackage. The
commands run by mmdebstrap are far from that trivial to reproduce. I've yet
to see a good use-case for dropping to an interactive shell for *and* failed
command (not just hooks).

To give you an idea of why it's really far from simple to just re-run a command
run by mmdebstrap have a look at this:

https://sources.debian.org/src/mmdebstrap/1.3.5-7/mmdebstrap/#L486

If any of that fails, what good is an interactive shell going to do?

I think what you ultimately want with the interactive bash shell is to figure
out why the stuff that broke for you did break. But I can get you the same
information by increasing either the --verbose or --debug output as necessary.

When I said "plain apt" I meant the script below. After all, mmdebstrap is just
a wrapper around apt.

I think it is a bad example for the --failure-hook option because what you want
can also be achieved by better --verbose or --debug output.

Could you run your mmdebstrap invocation with --debug and paste(bin) the error
you get?

Thanks!

cheers, josch

Johannes Schauer Marin Rodrigues <josch@debian.org> writes:

Good to know. Thanks. Not relevant to me today because I don't have any
customization hooks, but I'm sure I will at some point.

Yeah. Certainly for some things there isn't a simple command you can
give to an interactive shell. But for some other things, there is, like
my apt server failure. I don't have a good sense of which case is more
common.

Yes and no. I can imagine that my apt server is misconfigured, and the
server will need a change to make this work. And to test potential
server fixes it would be much easier to run "apt update" repeatedly in
an interactive shell than doing a full mmdebstrap run. Doing a full run
each time can be much slower if the failing thing doesn't happen right
at the start. --verbose or --debug are good to diagnose problems, but
not to test potential fixes.

Let me try to get that tomorrow.