Re: sbuild on hurd-amd64...

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.

> > > > I don't really know where one would tell mmdebstrap to just use chroot.
> > > 
> > > That's --mode=root.
> > 
> > But we are not root here.
> > 
> > I mean, I understand what you mean technically, but that's not what
> > users will understand from the documentation. What I understand from
> > "--mode=root" is that mmdebstrap should be run as root (or be given
> > sudo rights), while it's not what we want to achieve. We still do need
> > fakeroot in the play to be able to get files recorded as seemingly root
> > and other debian users.
> 
> 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.

> > > Could you try this patch: https://paste.debian.net/hidden/8e5bf3c7/
> > > 
> > > And then run mmdebstrap with --skip=check/root,check/canmount which should
> > > disable both checks that made it fail before and then hopefully you get a bit
> > > further.
> > 
> > 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.

> > > Except that fakeroot is not doing chroot at all.
> > 
> > We are misunderstanding each other because we are not talking about the
> > same views.
> 
> 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.

> > > And even fakeroot+fakechroot is not doing any actual chroot. It's just
> > > intercepting and modifying syscalls.
> > 
> > I mean from the calling perspective, not from the actual technical
> > things that get achieved.
> > 
> > I know the latter. But I don't know the mmdebstrap code at all (and have
> > just no time available to study it), but I'm quite sure that the code
> > path that mmdebstrap already has to call fakeroot+fakechroot would be
> > essentially the same to call fakeroot-hurd+chroot. And you do not need
> > any particular hurdish knowledge there: fakeroot-hurd is usable exactly like
> > fakeroot-tcp/sysv,
> 
> 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.

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

Samuel