Hi Charles, Quoting Carlos Henrique Lima Melara (2024-07-07 00:07:03) > I'm CC'ing 1075871, but if you you're the only maintainer I can add -quiet. > Just let me know.
I think it's better to have all bug communication in public even though it's
unlikely that any of the other sbuild contributors replies here. I don't know
if people like Jochen or Christian are subscribed to the bug mails.
> Yes, it's a thin wrapper (I think, don't speak perl, sorry). But the
> problem is the last step where it chroot (plain chroot, nothing fancy)
> to do an apt update. There it just invoke chroot but don't mount /proc
> inside the chroor and then this triggers the fallback behaviour of
> gpg-agent (exhaustively closing fds on a fork). It's the following
> section of sbuild-createchroot that do the update [1]:
>
> if (!$conf->get('SETUP_ONLY') || !$conf->get('MAKE_SBUILD_TARBALL')) {
> # FIXME: also update packages with the unshare backend
> if ($conf->get('ARCH') eq $conf->get('HOST_ARCH') &&
> $conf->get('CHROOT_MODE') ne 'unshare') {
> my $session = Sbuild::ChrootPlain->new($conf, $target);
> my $host = Sbuild::ChrootRoot->new($conf);
> if (defined($session)) {
> $session->set('Log Stream', \*STDOUT);
>
> if (!$session->begin_session() || !$host->begin_session()) {
> print STDERR "E: Error creating chroot session: skipping apt
> update\n";
> } else {
> my $resolver = Sbuild::AptResolver->new($conf, $session,
> $host);
> $resolver->setup();
>
> In sbuild-update, it begins a new schroot source session with sbuild -
> and here sbuild/schroot mounts /proc so gpg-agent use it to only close
> the open fds. That's the main difference between sbuild-update and
> sbuild-createchroot's update step.
Ah, you are right. Even though I find it very odd that gpg chose to de-facto
require mounted /proc to operate, I think this code path would benefit from
having a bit more of a setup so that processes run inside the chroot can feel a
bit more like home.
> > Also, why are you using sbuild-createchroot? Are you trying to set up the
> > initial schroot configuration?
>
> Yes, to create a schroot to use with sbuild. Mainly as a convenience
> script instead of using debootstrap.
Good. That's its intended use.
I am not using the schroot backend and when I did in the past, I used it
exclusively with tarballs. You seem to be creating directory-based chroots for
schroot. This is nothing that I am using in my daily sbuild usage, which
probably explains why I'm not running into bugs like these.
If you can supply a patch that does the right thing, that'd make me very happy.
As I'm not using schroot anymore, my motivation to fix this is low but it'll be
put on the TODO list.
For anybody having a go at fixing the issue, maybe it would be best to use the
ChrootUnshare backend for $session instead of ChrootPlain. The code is run as
the superuser anyways.
Thanks!
cheers, josch
signature.asc
Description: signature
