Hi, Quoting Dima Kogan (2023-05-30 20:48:59) > Johannes Schauer Marin Rodrigues <[email protected]> writes: > > 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. > 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.
let me tell you about another trick. Instead of running --customize-hook='chroot "$1" i-might-fail || chroot "$1" bash' you can also run: --chrooted-customize-hook='i-might-fail || bash' In contrast to the --X-hook options, the --chrooted-X-hook options run their arguments inside the chroot and thus save you quite a bit of typing. The --chrooted-X-hook options do a bit more than that but those things are not relevant here. The options are currently undocumented but I think I'll make them official with the next release. > > 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? > > 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. 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? > > 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. > > Good to know. I admittedly haven't spent a ton of time working on it. 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. > > 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. > > 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. When I said "plain apt" I meant the script below. After all, mmdebstrap is just a wrapper around apt. > > 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. > > 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. 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
signature.asc
Description: signature
