|
From: | Brad Smith |
Subject: | Re: [RFC PATCH for-7.1] Remove the slirp submodule (and only compile with an external libslirp) |
Date: | Sat, 23 Apr 2022 18:06:07 -0400 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Thunderbird/100.0 |
On 4/20/2022 6:13 AM, Thomas Huth wrote:
On 19/04/2022 18.24, Daniel P. Berrangé wrote:On Mon, Apr 11, 2022 at 08:55:19AM +0200, Thomas Huth wrote:On 11/04/2022 01.50, Brad Smith wrote:On 4/10/2022 5:06 AM, Peter Maydell wrote:On Sun, 10 Apr 2022 at 05:51, Brad Smith <brad@comstyle.com> wrote:On 4/8/2022 12:47 PM, Thomas Huth wrote:QEMU 7.1 won't support Ubuntu 18.04 anymore, so the last big important distro that did not have a pre-packaged libslirp has been dismissed.All other major distros seem to have a libslirp package in their distribution already - according to repology.org: Fedora 34: 4.4.0 CentOS 8 (RHEL-8): 4.4.0 Debian Buster: 4.3.1 (in buster-backports) OpenSUSE Leap 15.3: 4.3.1 Ubuntu LTS 20.04: 4.1.0 FreeBSD Ports: 4.6.1 NetBSD pkgsrc: 4.3.1 Homebrew: 4.6.1 MSYS2 mingw: 4.6.1 The only one that still seems to be missing a libslirp package is OpenBSD - but I assume that they can add it to their ports system quickly if required.I wish I had seen this earlier as our 7.1 release was just tagged.I have whipped up a port of 4.6.1 for OpenBSD as it was pretty simple. Iwill see about submitting it in a number of days when the tree opens.How awkward would it be for an end-user who's on OpenBSD 7.1 to build a QEMU that doesn't have libslirp? (That is, is it easy and common for an end user to pull in a port of libslirp that only came along in a later OpenBSD, or would they instead have to manually compile libslirp themselves from the upstream sources?) (I'm asking here because if it's painful, then we should perhaps defer dropping our submodule copy of libslirp a little longer.) thanks -- PMMThey would have to pull down a -current ports tree and build it. No package would exist for the release. It is possible, but not "supported". I havenot looked at the CI bits to see how difficult that would be.Our release cycles are 6 months and the next release will be in the middleof October.OK, thanks for the update, Brad ... so I guess we should defer this patch toQEMU 7.2 (to be released in december) instead?(which would be fine for me - I just wanted to get the discussion started,that's also why I've marked this patch as RFC)Perhaps make 7.1 simply issue a warning message in configure if the bundled slirp is used, to give people a heads up that they'll want to install libslirp-devel soon.Not sure if people will notice a warning in the output of "configure" ... but I've put some sentences in the ChangeLog here:https://wiki.qemu.org/ChangeLog/7.0#New_deprecated_options_and_features (which we could repeat for the 7.1 release again) I hope that helps to make people aware... Thomas
Just to note.. my libslirp port went in. https://marc.info/?l=openbsd-ports-cvs&m=165070969206193&w=2 and have switched our QEMU port to build with the libslirp port.. https://marc.info/?l=openbsd-ports-cvs&m=165070979906266&w=2
[Prev in Thread] | Current Thread | [Next in Thread] |