Re: sbuild on hurd-amd64...

Johannes Schauer Marin Rodrigues <[email protected]> Sun, 07 Sep 2025 13:46:41 +0200
Newsgroups	gmane.linux.debian.ports.hurd
Message-ID	<175724560114.547767.10594637446461735251@localhost>
Hi again,

Quoting Samuel Thibault (2025-09-07 01:48:11)
> Johannes Schauer Marin Rodrigues, le dim. 07 sept. 2025 01:36:04 +0200, a ecrit:
> > Is what you are saying that under Hurd, mmdebstrap should be doing the same
> > convenience calling of fakeroot-hurd as it currently does for "fakechroot
> > fakeroot" such that the user does not have to prefix the call with
> > fakeroot-hurd?
> 
> Yes.
> 
> And it does not need to be running inside fakechroot to be able to call
> chroot.

okay, that should be easy to implement.

> > That sounds more like you'd like a differently named alias for the same
> > option then?
> Possibly, but to my mind it really looks like fakeroot, since that's what we
> are doing.

Okay, if you think that this would be least confusing for hurd users, then
mmdebstrap could just overload the existing --mode=fakeroot mode with different
functionality (i.e. re-exec mmdebstrap under fakeroot-hurd) if mmdebstrap is
executed on hurd.

Do you think it would make sense to add an extra alias like
--mode=fakeroot-hurd? I envision that if the user calls mmdebstrap without
--mode, then the default mode (auto) should be selecting fakeroot(-hurd) on
hurd but if the user wants to be explicit, they would run it with fakeroot-hurd
to replace auto-detection with explicit mode selection. Having fakeroot-hurd as
anothera alias for fakeroot would also slightly help with documenting. What do
you think?

> > > But then permissions will be all wrong, we need fakeroot for that.
> > 
> > Yes, I mean, run:
> > 
> > fakeroot-hurd mmdebstrap --mode=root --skip=check/root,check/canmount ...
> > 
> > I agree that this is not a good UI yet
> I understand the part about --skip that would go away eventually. But what
> looks odd to me is using --mode=root: according to the manual one would have
> to be root or allow sudo. Here I would have much more understood writing
> --mode=fakeroot.

Okay, lets forget about --mode=root. Since fakeroot-hurd is meant to be run as
a prefix to the mmdebstrap command it is a better fix for --mode=fakeroot.

> > Yes, it's possible we are having a misunderstanding. I'd like to offer
> > having a video call (jitsi.debian.social)
> 
> I'm afraid I really can't make it.
> 
> I litteraly have almost one hundred mails waiting since my vacation
> start early august, and I have a lot other activies that impose
> difficult time scheduling.
> 
> I just don't have time on my hands, I can barely keep up with answering
> with what I can remember off-hand. I can't do more.

Please do not worry. You probably saw my mail to João Pedro Malhado in bug
#1104405 which apparently took me 4 months to reply to. I'm currently on
vacation and am sloooowly working down my email inbox. Around May/June I barely
had any time for Debian because of exam season. I do not mean to put any
pressure on you. Please do what is best for you. I hope we all do this because
we have fun with this and I do not want to make working on Debian less fun for
somebody else.

That being said, I think we got to the bottom of the misunderstanding (I hope)
and the next thing to do is for me to create a QEMU VM with hurd and try this
out myself. As I said, since the mmdebstrap testsuite runs inside qemu, I could
even add hurd tests to the mmdebstrap testsuite to avoid regressions in the
future.

As far as I'm concerned, running this on hurd should *just work* and create a
usable tarball:

    mmdebstrap unstable chroot.tar

> > In that case, (as i outlined above) mmdebstrap could re-exec itself under
> > fakeroot-hurd as it does for fakechroot/fakeroot right now when it is run
> > on hurd with --mode=auto and/or a new --mode=fakeroot-hurd or just
> > --mode=hurd. Is that what you mean?
> 
> Yes, though I would really simply call it --mode=fakeroot, since that's
> really what we are doing.

Okay. Lets do that!

> > > and chroot is just the normal chroot as one would use it on linux.
> > 
> > And here you mean the chroot *binary* in /usr/sbin, right?
> 
> Yes. Or the chroot() function: both will work fine as non-root.

Perfect. Next on my todo list is to fix img2pdf, then mmdebstrap, then sbuild
and *then* I'll have time for this.

I'll keep you all updated.

Thanks!

cheers, josch
signature.asc (application/pgp-signature, 833 B)