#1127407 autopkgtest-virt-qemu times out preparing glycin testbed

#1127407#5
Date:
2026-02-08 08:07:30 UTC
From:
To:
Hi,


It seems like we currently can't support glycin on qemu on
ci.debian.net. Every test that ran ends with a timeout (after 3000
seconds) installing the test dependencies which leads to a tmpfail. I
tried to debug a bit but didn't spot yet where it goes wrong (the output
of apt is hidden while running, even with -ddd). Running the apt command
(see below, I added the starting and leading quote because otherwise
things go wrong) from the log [1] manually in a qemu testbed I got for
testing src:hello works as expected and installation took something in
the order of 1 minute.

Paul

[1] https://ci.debian.net/packages/g/glycin/testing/amd64/68505740/

/usr/bin/eatmydata apt-get --quiet --assume-yes -o=APT::Status-Fd=3
-o=APT::Install-Recommends=false -o=DPkg::Lock::Timeout=300 
-o=Dpkg::Options::=--force-confnew -o=Debug::pkgProblemResolver=true 
satisfy 'debhelper-compat (= 13), dh-sequence-gir, meson (>= 0.57),
gobject-introspection, valac, gir1.2-gdk-4.0-dev [amd64 arm64 armhf i386
loong64 ppc64el riscv64 s390x ppc64] <!pkg.glycin.nogtk4>,
gir1.2-gobject-2.0-dev, gir1.2-gio-2.0-dev, libcairo2-dev (>= 0.17.0),
liblcms2-dev, libgtk-4-dev [amd64 arm64 armhf i386 loong64 ppc64el
riscv64 s390x ppc64] <!pkg.glycin.nogtk4>, libheif-dev (>= 1.17.0),
libjxl-dev (>= 0.11.0), libseccomp-dev, librsvg2-dev (>= 2.52.0),
cargo:native, librust-async-fs-2+default-dev (>= 2.1.0-~~),
librust-async-global-executor-3+default-dev,
librust-async-io-2+default-dev (>= 2.3.2-~~),
librust-async-lock-3+default-dev (>= 3.3.0-~~),
librust-async-task-4+default-dev, librust-bitflags-2+default-dev (>=
2.9.0-~~), librust-blocking-1+default-dev (>= 1.6.1-~~),
librust-cairo-rs-0.21+default-dev,
librust-env-logger-0.11+humantime-dev, librust-four-cc-0.4+default-dev,
librust-futures-channel-0.3+default-dev (>= 0.3.30-~~),
librust-futures-lite-2+default-dev (>= 2.1.0-~~),
librust-futures-task-0.3+default-dev (>= 0.3.30-~~),
librust-futures-timer-3+default-dev (>= 3.0.3-~~),
librust-futures-util-0.3+default-dev (>= 0.3.30-~~),
librust-gdk4-0.10+default-dev [amd64 arm64 armhf i386 loong64 ppc64el
riscv64 s390x ppc64] <!pkg.glycin.nogtk4>, librust-gdk4-0.10+v4-16-dev
[amd64 arm64 armhf i386 loong64 ppc64el riscv64 s390x ppc64]
<!pkg.glycin.nogtk4>, librust-gif-0.13+default-dev (>= 0.13.3-~~),
librust-gio-0.21+default-dev, librust-gio-0.21+v2-62-dev,
librust-glib-0.21+default-dev, librust-glib-0.21+v2-68-dev,
librust-glycin-3+async-io-dev (>= 3.0.7-~~),
librust-glycin-3+gobject-dev (>= 3.0.7-~~), librust-glycin-3-dev (>=
3.0.7-~~), librust-glycin-common-1+default-dev,
librust-glycin-utils-4+async-io-dev (>= 4.0.3-~~),
librust-glycin-utils-4+image-rs-dev (>= 4.0.3-~~),
librust-glycin-utils-4+loader-utils-dev (>= 4.0.3-~~),
librust-glycin-utils-4-dev (>= 4.0.3-~~),
librust-gufo-0.3+all-image-formats-dev, librust-gufo-0.3+default-dev,
librust-gufo-common-1+default-dev (>= 1.0.1-~~),
librust-gufo-common-1+serde-dev (>= 1.0.1-~~),
librust-gufo-exif-0.3+default-dev, librust-gufo-jpeg-0.3+default-dev,
librust-gufo-jpeg-0.3+encoder-dev, librust-half-2+default-dev (>=
2.4.1-~~), librust-image-0.25+bmp-dev (>= 0.25.7-~~),
librust-image-0.25+dds-dev (>= 0.25.7-~~), librust-image-0.25+exr-dev
(>= 0.25.7-~~), librust-image-0.25+ff-dev (>= 0.25.7-~~),
librust-image-0.25+gif-dev (>= 0.25.7-~~), librust-image-0.25+hdr-dev
(>= 0.25.7-~~), librust-image-0.25+ico-dev (>= 0.25.7-~~),
librust-image-0.25+jpeg-dev (>= 0.25.7-~~), librust-image-0.25+png-dev
(>= 0.25.7-~~), librust-image-0.25+pnm-dev (>= 0.25.7-~~),
librust-image-0.25+qoi-dev (>= 0.25.7-~~), librust-image-0.25+tga-dev
(>= 0.25.7-~~), librust-image-0.25+tiff-dev (>= 0.25.7-~~),
librust-image-0.25+webp-dev (>= 0.25.7-~~), librust-image-0.25-dev (>=
0.25.7-~~), librust-jpeg-encoder-0.6+default-dev,
librust-jpegxl-rs-0.11-dev, librust-jpegxl-sys-0.11-dev,
librust-lcms2-6+default-dev (>= 6.0.3-~~),
librust-lcms2-sys-4+default-dev (>= 4.0.4-~~),
librust-libc-0.2+default-dev (>= 0.2.152-~~),
librust-libheif-rs-2+v1-21-dev (>= 2.6.1-~~),
librust-librsvg-rebind-0.2+default-dev (>= 0.2.1-~~),
librust-libseccomp-0.4+default-dev, librust-log-0.4+default-dev,
librust-memfd-0.6+default-dev (>= 0.6.3-~~),
librust-memmap2-0.9+default-dev, librust-nix-0.30+default-dev,
librust-nix-0.30+fs-dev, librust-nix-0.30+resource-dev,
librust-nix-0.30+signal-dev, librust-paste-1+default-dev,
librust-png-0.17+default-dev, librust-rayon-1+default-dev (>=
1.10.0-~~), librust-rmp-serde-1+default-dev (>= 1.3.0-~~),
librust-safe-transmute-0.11+default-dev (>= 0.11.2-~~),
librust-serde-1+default-dev (>= 1.0.162-~~), librust-serde-1+derive-dev
(>= 1.0.162-~~), librust-static-assertions-1+default-dev (>= 1.1.0-~~),
librust-system-deps-7+default-dev, librust-thiserror-2+default-dev (>=
2.0.3-~~), librust-tokio-1+default-dev (>= 1.35.1-~~),
librust-tokio-1+fs-dev (>= 1.35.1-~~), librust-tokio-1+rt-dev (>=
1.35.1-~~), librust-tokio-1+rt-multi-thread-dev (>= 1.35.1-~~),
librust-tokio-1+time-dev (>= 1.35.1-~~),
librust-tokio-stream-0.1+default-dev (>= 0.1.15-~~),
librust-tokio-stream-0.1+fs-dev (>= 0.1.15-~~),
librust-tracing-0.1+default-dev (>= 0.1.40-~~),
librust-tracing-subscriber-0.3+default-dev,
librust-tracing-subscriber-0.3+env-filter-dev,
librust-tracing-subscriber-0.3+fmt-dev,
librust-yeslogic-fontconfig-sys-6+default-dev, librust-zbus-5+p2p-dev
(>= 5.10.0-~~), librust-zerocopy-0.8+default-dev (>= 0.8.12-~~),
librust-zune-jpeg-0.5+default-dev, librust-zvariant-5-dev (>= 5.4.0-~~),
libstd-rust-dev, rustc:native (>= 1.85), build-essential,
glycin-loaders, libheif-plugin-aomenc, libheif-plugin-x265, python3,
python3-gi, gir1.2-gly-2, gir1.2-glygtk4-2'

#1127407#10
Date:
2026-02-08 10:37:32 UTC
From:
To:
Feel free to remove glycin from the qemu ci.debian.net allow list if
we're not able to figure out how to fix this issue. I only requested
enabling it because I thought it would work, but I don't have
additional ideas with the information I have.

Thank you,
Jeremy Bícha

#1127407#15
Date:
2026-02-08 19:57:18 UTC
From:
To:
This has something to do with the way we communicate to the testbed
using unix sockets. I think those extra long command lines like your
[1] example is breaking something.

I have a reproducer:

1. Get a QEMU testbed up. Can be achieved by running a quick test with
--shell, so that autopkgtest will sit there waiting once the test is
done. I often use `gzip` for this.

2. `cd /tmp/autopkgtest-qemu.[random chars]`. Find the right directory
name in autopkgtest output, e.g.

  socat - UNIX-CONNECT:/tmp/autopkgtest-qemu.iehrg6hp/ttyS0

3. Run: `./runcmd echo $(tr -dc 'a-zA-Z' </dev/random | head -c 4)`.
That will run `echo [4 random chars]` on the testbed, output will
visible. Try a few times and check it's reliable.

4. Now run the same but with `head -c 4000`. This will break things.

For now I have no idea on how to fix this.

Paride