Hi everyone,

Several days ago here I reported that mmdebstrap'ping sh4 on an amd64 host failed as cited at the bottom of this email, and now it succeeds with no problem!

By the way, I am proposing to adapt autopkgtest-virt-qemu to guest architectures other than amd64 and i386, specifically to arm* and ppc64* at https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/100
which is a revised version of my previous MR.

The only problem in the latest autopkgtest-virt-qemu on gitlab
is that it assumes that a qemu VM has two serial ports, and tries to
attach two sockets on host to two serial ports of the guest.
On the other hand, arm* and ppc64* has only one serial port,
and the current autopkgtest-virt-qemu cannot attach two host sockets.

So I checked if the name of qemu-system-* is i386 or x86_64,
and attach one QEMU virtconsole to a guest unless i386 or x86_64 as https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/100/diffs

The QEMU sh4 virtual machine seems to have two serials in its guest VM.
So the current autopkgtest-virt-qemu on gitlab can theoretically work
on sh4 guests, and my proposal might break the functionality for sh4.
But I am unsure, because I do not have an sh4 QEMU disk image that can
boot without giving -kernel to qemu-system-sh4.

If you have any comments, please post them to https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/100

Best regards, Ryutaroh Matsumoto

From: Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
Subject: Re: mmdebstrap'ping sh4 failure on amd64 host
Date: Mon, 30 Nov 2020 11:12:16 +0900 (JST)

It will take two more days as there was a serious bug in the package
isc-dhcp [1] and the fix has been uploaded to the delayed queue [2].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957379
[2] https://ftp-master.debian.org/deferred.html

Adrian, thanks for the info. I will re-check the situation maybe in the next weekend (Dec. 5). Ryutaroh

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

On 12/4/20 02:27, Ryutaroh Matsumoto wrote:

By the way, I am proposing to adapt autopkgtest-virt-qemu to guest architectures other than amd64 and i386, specifically to arm* and ppc64* at https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/100
which is a revised version of my previous MR.

The only problem in the latest autopkgtest-virt-qemu on gitlab
is that it assumes that a qemu VM has two serial ports, and tries to
attach two sockets on host to two serial ports of the guest.
On the other hand, arm* and ppc64* has only one serial port,
and the current autopkgtest-virt-qemu cannot attach two host sockets.

So I checked if the name of qemu-system-* is i386 or x86_64,
and attach one QEMU virtconsole to a guest unless i386 or x86_64 as https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/100/diffs

The QEMU sh4 virtual machine seems to have two serials in its guest VM.
So the current autopkgtest-virt-qemu on gitlab can theoretically work
on sh4 guests, and my proposal might break the functionality for sh4.
But I am unsure, because I do not have an sh4 QEMU disk image that can
boot without giving -kernel to qemu-system-sh4.

I don't know what the current status is, but just as a heads-up: The sh4
port is in a better state now than it was last year and even the Debian
kernel package builds again on the buildds.

I haven't tested on qemu-system yet, but I expect it to work now since
the kernel image should be small enough.

Let me know what we need to do to get sh4 added to autopkgtest-virt-qemu.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)