Re: Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7

2018-12-14 Thread Simon McVittie 
On Fri, 14 Dec 2018 at 20:19:00 +0100, Matthias Klose wrote:
> On 14.12.18 12:48, Simon McVittie wrote:
> > On Fri, 14 Dec 2018 at 11:31:02 +, Simon McVittie wrote:
> >> tl;dr: autopkgtest-virt-qemu doesn't work with python3.7.
> > 
> > This seems to be caused by using socket.send() (and assuming the entire
> > buffer will be sent in one transaction) instead of socket.sendall().
> > This was always a bug, at least in theory. I don't know why Python 3.7
> > makes it significant in practice when it wasn't previously.
> 
> if you already ran autopkg using 3.7, then that might point out to the recent
> 3.7.2 release candidate 1. changes. At least the timing of the report 
> suggests this.

Well spotted, you are correct. Looking at apt/history.log and the timing
of my uploads, I must have run autopkgtest successfully with virt-qemu
and python3.7 3.7.1-1 while I was preparing flatpak 1.1.1-1.

The correlation with 3.7.2~rc1-1 seems very reliable, but I don't see
anything in the Python 3.7 news that looks like a likely trigger.

To be clear, I think this was always an autopkgtest-virt-qemu bug,
and I don't know why autopkgtest-virt-qemu worked so reliably in the past,
or why it still works with python3.6.

smcv

Re: Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7

2018-12-14 Thread Matthias Klose 
On 14.12.18 12:48, Simon McVittie wrote:
> Control: forwarded -1 
> https://salsa.debian.org/ci-team/autopkgtest/merge_requests/42
> Control: tags -1 + patch
> 
> On Fri, 14 Dec 2018 at 11:31:02 +, Simon McVittie wrote:
>> tl;dr: autopkgtest-virt-qemu doesn't work with python3.7.
> 
> This seems to be caused by using socket.send() (and assuming the entire
> buffer will be sent in one transaction) instead of socket.sendall().
> This was always a bug, at least in theory. I don't know why Python 3.7
> makes it significant in practice when it wasn't previously.

if you already ran autopkg using 3.7, then that might point out to the recent
3.7.2 release candidate 1. changes. At least the timing of the report suggests 
this.

https://docs.python.org/3.7/whatsnew/changelog.html#python-3-7-2-release-candidate-1

Re: Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7

2018-12-14 Thread Simon McVittie 
Control: forwarded -1 
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/42
Control: tags -1 + patch

On Fri, 14 Dec 2018 at 11:31:02 +, Simon McVittie wrote:
> tl;dr: autopkgtest-virt-qemu doesn't work with python3.7.

This seems to be caused by using socket.send() (and assuming the entire
buffer will be sent in one transaction) instead of socket.sendall().
This was always a bug, at least in theory. I don't know why Python 3.7
makes it significant in practice when it wasn't previously.

smcv

Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7

2018-12-14 Thread Simon McVittie 
Package: autopkgtest
Version: 5.6
Severity: important
File: /usr/bin/autopkgtest-virt-qemu
Control: found -1 5.7
Control: user debian-python@lists.debian.org
Control: usertags -1 + python3.7
X-Debbugs-Cc: debian-python@lists.debian.org

tl;dr: autopkgtest-virt-qemu doesn't work with python3.7. A short-term
workaround is to run it with python3.6, for example by using
"autopkgtest ... -- /usr/bin/python3.6 /usr/bin/autopkgtest-virt-qemu ...",
or changing its first line.

Steps to reproduce (minimal reproducer with just autopkgtest-virt-qemu,
not autopkgtest itself):

* Have an autopkgtest-virt-qemu VM image that previously worked (or see
  the man page for instructions to make one)
* Have python3.6 and python3.7, with python3.7 as default
* python3.7 /usr/bin/autopkgtest-virt-qemu --debug .../autopkgtest.qcow2
* wait for "ok"
* enter the command "open"
* wait for timeout or "ok /tmp/autopkgtest.XX" response
* if still running, enter the command "close", wait for "ok" response,
  and enter the command "quit"
* python3.6 /usr/bin/autopkgtest-virt-qemu --debug .../autopkgtest.qcow2
* wait for "ok"
* type "open"
* wait for timeout or "ok /tmp/autopkgtest.XX" response
* if still running, enter the command "close", wait for "ok" response,
  and enter the command "quit"

Expected result:

* In both cases you eventually get "ok /tmp/autopkgtest.XX" where
  XX is a random string

Actual result:

* With python3.6, we get the expected result
* With python3.7, setup_shared() times out (symptoms are similar to #892023):

$ autopkgtest-virt-qemu --debug 
~/.cache/vectis/amd64/debian/sid/autopkgtest.qcow2
ok
open
autopkgtest-virt-qemu: DBG: executing open
autopkgtest-virt-qemu: DBG: Creating temporary overlay image in 
/tmp/autopkgtest-qemu.r20th32n/overlay.img
autopkgtest-virt-qemu: DBG: execute-timeout: qemu-img create -f qcow2 -b 
/home/smcv/.cache/vectis/amd64/debian/sid/autopkgtest.qcow2 
/tmp/autopkgtest-qemu.r20th32n/overlay.img
autopkgtest-virt-qemu: DBG: find_free_port: trying 10022
autopkgtest-virt-qemu: DBG: find_free_port: 10022 is free
autopkgtest-virt-qemu: DBG: Forwarding local port 10022 to VM ssh port 22
autopkgtest-virt-qemu: DBG: Detected KVM capable Intel host CPU, enabling 
nested KVM
autopkgtest-virt-qemu: DBG: expect: " login: "
qemu-system-x86_64: warning: host doesn't support requested feature: 
CPUID.01H:ECX.vmx [bit 5]
autopkgtest-virt-qemu: DBG: expect: found ""login prompt on ttyS0""
autopkgtest-virt-qemu: DBG: expect: "ok"
autopkgtest-virt-qemu: DBG: expect: found ""b'ok'""
autopkgtest-virt-qemu: DBG: setup_shell(): there already is a shell on ttyS1
qemu-system-x86_64: terminating on signal 15 from pid 10760 (/usr/bin/python3)
autopkgtest-virt-qemu: DBG: cleanup...
: failure: timed out on client shared directory setup

Hacking in some extra debug shows that the thing that is timing out,
similar to #892023, is that the done_shared flag file in the 9p shared
file system is never created.

I tried applying the patches from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892023#10 to make our
shell screen-scraping more robust, but they didn't help.

When I added echo=True to all the expect() calls, I didn't see any output
from the commands that set up the shared directory (starting with
"mkdir -p -m 1777 /run/autopkgtest/shared").

I initially thought this was a regression with the new qemu 3, but this
was not the case: qemu 2 from testing exhibits the same symptoms.

smcv

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 
'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autopkgtest depends on:
ii  apt-utils   1.8.0~alpha2
ii  libdpkg-perl1.19.2
ii  procps  2:3.3.15-2
ii  python3 3.7.1-2
ii  python3-debian  0.1.33

Versions of packages autopkgtest recommends:
ii  autodep8  0.17

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
ii  ovmf  0~20181115.85588389-2
ii  qemu-efi-aarch64  0~20181115.85588389-2
pn  qemu-efi-arm  
ii  qemu-system   1:3.1+dfsg-1
ii  qemu-utils1:3.1+dfsg-1
ii  schroot   1.6.10-6+b1
pn  vmdb2 

-- no debconf information