[6/7] libslirp: add recipe to continue slirp support in qemu

qemu 7.2 no longer carries libslirp in-tree, and so
it has to be provided externally.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/conf/distro/include/maintainers.inc       |  1 +
 .../recipes-connectivity/slirp/libslirp_git.bb | 18 ++++++++++++++++++
 2 files changed, 19 insertions(+)
 create mode 100644 meta/recipes-connectivity/slirp/libslirp_git.bb

On Sat, 2022-12-24 at 17:59 +0100, Alexander Kanavin wrote:
> qemu 7.2 no longer carries libslirp in-tree, and so
> it has to be provided externally.
> 
> Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> ---
>  meta/conf/distro/include/maintainers.inc       |  1 +
>  .../recipes-connectivity/slirp/libslirp_git.bb | 18 ++++++++++++++++++
>  2 files changed, 19 insertions(+)
>  create mode 100644 meta/recipes-connectivity/slirp/libslirp_git.bb
> 
> diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc
> index 66797db02c..be96123ce6 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -382,6 +382,7 @@ RECIPE_MAINTAINER:pn-libsamplerate0 = "Unassigned <unassigned@yoctoproject.org>"
>  RECIPE_MAINTAINER:pn-libsdl2 = "Yi Zhao <yi.zhao@windriver.com>"
>  RECIPE_MAINTAINER:pn-libseccomp = "Unassigned <unassigned@yoctoproject.org>"
>  RECIPE_MAINTAINER:pn-libsecret = "Alexander Kanavin <alex.kanavin@gmail.com>"
> +RECIPE_MAINTAINER:pn-libslirp = "Unassigned <unassigned@yoctoproject.org>"
>  RECIPE_MAINTAINER:pn-libsm = "Unassigned <unassigned@yoctoproject.org>"
>  RECIPE_MAINTAINER:pn-libsndfile1 = "Unassigned <unassigned@yoctoproject.org>"
>  RECIPE_MAINTAINER:pn-libsolv = "Anuj Mittal <anuj.mittal@intel.com>"
> diff --git a/meta/recipes-connectivity/slirp/libslirp_git.bb b/meta/recipes-connectivity/slirp/libslirp_git.bb
> new file mode 100644
> index 0000000000..334b786b9b
> --- /dev/null
> +++ b/meta/recipes-connectivity/slirp/libslirp_git.bb
> @@ -0,0 +1,18 @@
> +SUMMARY = "A general purpose TCP-IP emulator"
> +DESCRIPTION = "A general purpose TCP-IP emulator used by virtual machine hypervisors to provide virtual networking services."
> +HOMEPAGE = "https://gitlab.freedesktop.org/slirp/libslirp"
> +LICENSE = "BSD-3-Clause & MIT"
> +LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=bca0186b14e6b05e338e729f106db727"
> +
> +SRC_URI = "git://gitlab.freedesktop.org/slirp/libslirp.git;protocol=https;branch=master"
> +SRCREV = "3ad1710a96678fe79066b1469cead4058713a1d9"
> +PV = "4.7.0"
> +S = "${WORKDIR}/git"
> +
> +DEPENDS = " \
> +    glib-2.0 \
> +"
> +
> +inherit meson pkgconfig
> +
> +BBCLASSEXTEND = "native nativesdk"

I did merge this to core since the qemu upgrade has some potential wins
for us and is fairly important to get in. I probably shouldn't have
done as people are now upset, we're now seeing autobuilder failures,
people are on vacation and the issues won't be fixed until mid January.

I've had some feedback about the way this was handled. In future things
might be smoother if we:

a) make sure the maintainers of other layers containing such recipes 
   are cc'd on the changes.
b) mention in the commit which layer a recipe came from and who worked 
   on the underlying code
c) mention any changes made to merge to core
d) time things outside of holidays

Yes, it is a pain to do some of these things and sightly more work, but
leaving the issues to me isn't much fun either. I don't think anything
was intended by anything, it was mainly a desire to keep core up to
take and be able to take advantaged of new features in qemu.

I am very much aware that during holidays, people have different time
availability and this sometimes works in favour of productivity,
sometimes against it. I need to balance getting patch movement and
feedback back to contributors with some people taking a proper break
and it is hard to get right.

For the record, looking at a diff, the changes in this submission
appear to be:

* Upgrade from 4.6.1+git -> 4.7.0
* Addition of BBCLASSEXTEND for native/nativesdk
* Add DESCRIPTION and HOMEPAGE

Cheers,

Richard

On Wed, 28 Dec 2022 at 14:42, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I've had some feedback about the way this was handled. In future things
> might be smoother if we:
>
> a) make sure the maintainers of other layers containing such recipes
>    are cc'd on the changes.
> b) mention in the commit which layer a recipe came from and who worked
>    on the underlying code
> c) mention any changes made to merge to core
> d) time things outside of holidays

I agree with documenting origin, giving credit and making
changes-on-top clear; I did copy the recipe (however simple) from
meta-virtualization and should've done that at that point.

Otherwise, there's no 'evil intent' with the timing. It's just that
recent AUH reports (and associated weekly CVE reports for master)
bother me more and more, Christmas season is a great time to get
actual work done :) and I handle hardest updates first - and qemu is
certainly in that category. I wouldn't do these large, disruptive,
inconveniently timed (for some) update batches if we had a healthy
maintainer ecosystem.

By the way, at Linutronix there is a requirement to clearly document
code that's been copied from elsewhere, one is not allowed to change
it in the same commit, and there's associated nomenclature for commit
messages. For example, recently I wrote this into a commit:

    (copy from external source:
    git: git://git.yoctoproject.org/poky
    archive: c615d00a361510b0425a57ea6afdda5a39069692
    copy: meta/recipes-core/initrdscripts/files/init-install-efi.sh
--> recipes-core/images/initramfs-module-someproduct-install/someproduct-partition-install.sh
    copy: meta/recipes-core/initrdscripts/files/init-install-efi.sh
--> recipes-core/images/initramfs-module-someproduct-install/someproduct-reinstall.sh
    )


Alex