Dear Maintainer,

I made an autopkg qemu testbed by debci setup -f -s sid -a amd64 -b qemu.
Then I run autopkgtest -B -U -u debci gvfs -- qemu
It always fails with


autopkgtest [11:13:45]: test integration: [-----------------------

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
sudo: a password is required
autopkgtest [11:13:46]: test integration: -----------------------]
autopkgtest [11:13:46]: test integration:  - - - - - - - - - - results - - - - - - - - - -
integration          FAIL non-zero exit status 1


This seems a bug in testsuite. The log is attached.

Best regards, Ryutaroh Matsumoto

...

This test needs to run as an ordinary user who can sudo, and autopkgtest
doesn't support that. Just running as root doesn't work: the gvfs tests
expect to run in an ordinary user's login session, so that the gvfs
daemons themselves run as that user, but the test escalates privileges to
root to set up things like Samba to test against.

I'm told this works in Ubuntu, because Ubuntu runs tests in cloud images
with passwordless sudo available for the 'ubuntu' user by default.

We probably need a new needs-sudo restriction that will make autopkgtest
set up the ordinary user to have passwordless sudo.

    smcv

Hi Simon,
Thank you very much for the explanation.
Previously reported another issue to src:libnfs
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983362
seems to be caused by the same machanism.

Should #983362 and #983367 be merged and reassigned to autopkgtest?

Bes regards, Ryutaroh

From: Simon McVittie <smcv@debian.org>
Subject: Re: Bug#983367: gvfs: autopkg test always fails on qemu testbed
Date: Tue, 23 Feb 2021 08:39:16 +0000

I was told that autopkg test scripts should not assume that an ordinary user can sudo at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983432#10

Hi Ryutaroh.

This can be looked at several ways and thank you for collecting a few opinions.

As Simon pointed out passwordless sudo is available in Ubuntu test
images (both for VMs and LXC runners), thus it is not a surprise that
tests started relying on that. IMO making passwordless sudo available
is the most pleasant way of enabling testing as a normal user and
still allowing raising privileges for a few operations.
On Ubuntu isolation-container and isolation-machine will keep implying
passwordless sudo being available and IMO the easiest solution forward
would be generating Debian test images the same way. Personally I'd
like to see Debian executing the tests using sudo and any other way
would be just more complicated.

The needs-sudo restriction can be a good way of documenting the tests'
requirements and the test runners' capability.

Should none of the above would be adopted in Debian I can make the
test SKIP if sudo fails.

Cheers,
Balint