On Wed, Sep 11, 2024 at 12:32 PM Michal Orzel <[email protected]> wrote:
> > > On 11/09/2024 15:50, Bruce Ashfield wrote: > > > > > > > > > > > > On Wed, Sep 11, 2024 at 5:31 AM Michal Orzel <[email protected] > <mailto:[email protected]>> wrote: > > > > It should match the master recipe of Xen hypervisor which sets > XEN_REL > > to 4.19. > > > > > > While on the master branch, the current SRCREV of the tools is 4.18 based > > (at least in my checking). I was going to bump _git just before the > release as > > I didn't want to it to exactly match 4.19 when I was adding the new > recipes. > If both xen and xen_tools specify the same commit SHA, we should use the > same XEN_REL. > Otherwise it looks strange. The issue is also with scarthgap, where we > observe warnings > due to this difference (i.e. tools specify 4.18 instead of 4.19). > The xen_git is incorrect (fom the maintenance perspective), and hadn't noticed iit. I think I've mentioned before (on the list, not in this Xen context) that versioning shouldn't be aspirational. If there's no tag or -rc in play, then it normally uses the last tag/release + git<srcrev>. The +git keeps the version separate and moving forward until the tag. I'd rather not have many exceptions based on the myriad of ways projects do their tagging and versioning. But let's leave it as-is in master (for now), as I'd rather not have version numbers going backwards as we need to use PE to fix package feeds, etc. master will be fixed when I move _git to 4.20+ As for scarthgap, it could be fixable via a move to 4.18 and the addition of PE to keep the number going forward. The _git recipes are largely there for dev purposes (and hedging some bets), so they aren't checked as heavily. See the recent discussion about adding the 4.19 recipes to scarthgap (but leaving the default on 4.18), since that would get us a more supportable 4.19 than the _git recipes typically provide. > > > > > > > > > Also, take opportunity to remove no longer needed patches. > > > > > > We should log why they are unneeded in the commit. Yes it is obvious > > in most cases, but a one line statement for them helps me when I'm > > looking later. > Ok. > > > > > > > > > > > Signed-off-by: Michal Orzel <[email protected] <mailto: > [email protected]>> > > --- > > We could also update xen and tools to 4.20 right away to reflect the > current > > development version but I'm not sure if we want to do it at this > point. > > > > > > See above: that is already my plan for the next few weeks. I'll move _git > > away from 4.19 so the _git will be available in the release. It is ok for > > them to be unfinished and in development in that recipe. > Do you mean that we should drop this patch completely because you are > going to > bump master recipes to XEN_REL ?= 4.20 development branch (i.e. current > master) > in the upcoming weeks? > I can just clean them up locally, or send the patch for that. Either works. I wouldn't couple it to work on rel 4.20. When I dropped 4.17, I zombied the patches and didn't notice. > > > > > > > > Unrelated question: > > When vmsep is enabled, the tools recipe RRECOMMENDS qemu-x86_64 and > qemu-i386. > > What is the reason behind it given that the only qemu that is needed > in the > > target rootfs for Xen is qemu-system-i386? What would be the best > way to build > > only the QEMU required by Xen (upstream) and not all the possible > combinations? > > > > > > I'm not concerned about extra building of qemu components, it is only > I am concerned. It takes definitely more time which is something we can > observe in our upstream Xen CI. > The less time we spend in the CI loop, the more patches we can test. > RRECOMMDENDs are just packages. There's going to be no difference in build time by changing them. All of qemu is build no matter what, just how they are put into packages changes based on the recipe and then pulled in via rdepends/rreccomends. If we were removing the entire dependency by dropping them from rrecommends, then we'd save build time. > > > an issue if they are installed on the target (which of course they are > > if images are configured to add rreccomends automatically). > Yes, both user and system qemu for all the arches gets installed in the > target. > > Definitely. I was just providing context to say that at the moment it is intentional via the history of the packaging and what we needed before. > > > > That's why meta-virt was the first part of the ecosystem to even offer > > split qemu packages. It was all or nothing before that. You can see > > that in some of the image recipes that I'm still working on fixing up. > > This is an artifact / holdover from that history. > > > > The vmsep based splitting covers quite a few different runtimes so it is > > a bit different than OEcore splitting, and I've kept it for > compatibility with > > other layers. > > > > We can absolutely change our rrecommends in the recipes. In the short > > term, you could always :remove the packages you don't want and/or > > configure your build to not automatically install rreccomends (but that > > is more drastic and will likely break more). > > > > IIRC (and as you are saying) xen uses i366-system regardless of the > > xen-host (target) architecture, so it does look like we should move > > to qemu-i386-system for that rrecommend. > Yes, that's what I'm saying. Will you look into it or should I send a > patch? > Yup. Just be warned that it won't help build time, but will make the runtime smaller. Bruce > > ~Michal > > > > > Bruce > > > > > > --- > > ...ython-pygrub-pass-DISTUTILS-xen-4.15.patch | 73 > ------------------- > > ...enstored_control.c-correctly-print-t.patch | 34 --------- > > recipes-extended/xen/xen-tools_git.bb <http://xen-tools_git.bb> > | 2 +- > > 3 files changed, 1 insertion(+), 108 deletions(-) > > delete mode 100644 > recipes-extended/xen/files/0001-python-pygrub-pass-DISTUTILS-xen-4.15.patch > > delete mode 100644 > recipes-extended/xen/files/0001-tools-xenstore-xenstored_control.c-correctly-print-t.patch > > > > diff --git > a/recipes-extended/xen/files/0001-python-pygrub-pass-DISTUTILS-xen-4.15.patch > b/recipes-extended/xen/files/0001-python-pygrub-pass-DISTUTILS-xen-4.15.patch > > deleted file mode 100644 > > index 476f5ddcf1c6..000000000000 > > --- > a/recipes-extended/xen/files/0001-python-pygrub-pass-DISTUTILS-xen-4.15.patch > > +++ /dev/null > > @@ -1,73 +0,0 @@ > > -From 6db88791d923167f160afbcadeffad84a4cbdbc5 Mon Sep 17 00:00:00 > 2001 > > -Message-Id: < > 6db88791d923167f160afbcadeffad84a4cbdbc5.1612262706.git.bertrand.marq...@arm.com > <mailto: > 6db88791d923167f160afbcadeffad84a4cbdbc5.1612262706.git.bertrand.marq...@arm.com > >> > > -From: Maciej Pijanowski <[email protected] <mailto: > [email protected]>> > > -Date: Fri, 19 Oct 2018 11:01:37 +0200 > > -Subject: [PATCH] python,pygrub: pass DISTUTILS env vars as setup.py > args > > - > > -Upstream-Status: Inappropriate [oe specific, python install issues] > > - > > -Allow to respect the target install dir (PYTHON_SITEPACKAGES_DIR) > > -as well as other parameters set by the OpenEmbedded build system. > > -This is especially useful when the target libdir is not the default > one > > -(/usr/lib), but for example /usr/lib64. > > - > > -Signed-off-by: Maciej Pijanowski <[email protected] > <mailto:[email protected]>> > > - > > -Forward-ported to Xen 4.12.0 > > -Signed-off-by: Christopher Clark <[email protected] > <mailto:[email protected]>> > > - > > -Modified to support pygrub installation with python 3 > > -Signed-off-by: Christopher Clark <[email protected] > <mailto:[email protected]>> > > - > > -Forward-ported to Xen 4.14.0 > > -Signed-off-by: Christopher Clark <[email protected] > <mailto:[email protected]>> > > - > > -Forward-ported to Xen 4.15.0 > > -Signed-off-by: Bertrand Marquis <[email protected] <mailto: > [email protected]>> > > - > > ---- > > - tools/pygrub/Makefile | 7 +++++-- > > - tools/python/Makefile | 2 +- > > - 2 files changed, 6 insertions(+), 3 deletions(-) > > - > > -diff --git a/tools/pygrub/Makefile b/tools/pygrub/Makefile > > -index 37b2146214..ffb9270065 100644 > > ---- a/tools/pygrub/Makefile > > -+++ b/tools/pygrub/Makefile > > -@@ -10,7 +10,7 @@ INSTALL_LOG = build/installed_files.txt > > - all: build > > - .PHONY: build > > - build: > > -- CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDSHARED="$(CC)" > LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py build > > -+ CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDSHARED="$(CC)" > LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py build $(DISTUTILS_BUILD_ARGS) > > - > > - .PHONY: install > > - install: all > > -@@ -18,7 +18,10 @@ install: all > > - CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDSHARED="$(CC)" \ > > - LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) setup.py install \ > > - --record $(INSTALL_LOG) $(PYTHON_PREFIX_ARG) \ > > -- --root="$(DESTDIR)" > --install-scripts=$(LIBEXEC_BIN) --force > > -+ --root="$(DESTDIR)" > --install-scripts=$(LIBEXEC_BIN) --force \ > > -+ $(DISTUTILS_INSTALL_ARGS) > > -+ rm -f $(DESTDIR)/$(LIBEXEC_BIN)/pygrub > > -+ $(INSTALL_PYTHON_PROG) src/pygrub > $(DESTDIR)/$(LIBEXEC_BIN)/pygrub > > - set -e; if [ $(bindir) != $(LIBEXEC_BIN) -a \ > > - "`readlink -f $(DESTDIR)/$(bindir)`" != \ > > - "`readlink -f $(LIBEXEC_BIN)`" ]; then \ > > -diff --git a/tools/python/Makefile b/tools/python/Makefile > > -index cc76423647..5cb11ae453 100644 > > ---- a/tools/python/Makefile > > -+++ b/tools/python/Makefile > > -@@ -12,7 +12,7 @@ setup.py = CC="$(CC)" CFLAGS="$(PY_CFLAGS)" > LDSHARED="$(CC)" LDFLAGS="$(PY_LDFLA > > - SHLIB_libxenctrl="$(SHLIB_libxenctrl)" \ > > - SHLIB_libxenguest="$(SHLIB_libxenguest)" \ > > - SHLIB_libxenstore="$(SHLIB_libxenstore)" \ > > -- $(PYTHON) setup.py > > -+ $(PYTHON) setup.py $(DISTUTILS_BUILD_ARGS) > > - > > - .PHONY: build > > - build: > > --- > > -2.17.1 > > - > > diff --git > a/recipes-extended/xen/files/0001-tools-xenstore-xenstored_control.c-correctly-print-t.patch > b/recipes-extended/xen/files/0001-tools-xenstore-xenstored_control.c-correctly-print-t.patch > > deleted file mode 100644 > > index bf99f5e8c54c..000000000000 > > --- > a/recipes-extended/xen/files/0001-tools-xenstore-xenstored_control.c-correctly-print-t.patch > > +++ /dev/null > > @@ -1,34 +0,0 @@ > > -From c7c43c4531fe1cd188f62d9905c3f5c7a29a6fb0 Mon Sep 17 00:00:00 > 2001 > > -From: Alexander Kanavin <[email protected] <mailto: > [email protected]>> > > -Date: Wed, 12 Apr 2023 10:30:18 +0200 > > -Subject: [PATCH] tools/xenstore/xenstored_control.c: correctly > print time_t > > - > > -On 32 bit systems with 64 bit time_t (hello, Y2038 problem), > > -the following error occurs otherwise: > > - > > -| xenstored_control.c: In function 'lu_reject_reason': > > -| xenstored_control.c:646:70: error: format '%ld' expects argument > of type 'long int', but argument 5 has type 'time_t' {aka 'long long int'} > [-Werror=format=] > > - > > -Upstream-Status: Submitted [by email to > [email protected] <mailto:[email protected]> > and maintainers as suggested by add_maintainers.pl < > http://add_maintainers.pl> script] > > -Signed-off-by: Alexander Kanavin <[email protected] <mailto: > [email protected]>> > > ---- > > - tools/xenstore/xenstored_control.c | 4 ++-- > > - 1 file changed, 2 insertions(+), 2 deletions(-) > > - > > -diff --git a/tools/xenstore/xenstored_control.c > b/tools/xenstore/xenstored_control.c > > -index d1aaa00bf4..8d318c0399 100644 > > ---- a/tools/xenstore/xenstored_control.c > > -+++ b/tools/xenstore/xenstored_control.c > > -@@ -643,10 +643,10 @@ static const char *lu_reject_reason(const > void *ctx) > > - list_for_each_entry(conn, &connections, list) { > > - if (conn->ta_start_time && > > - (now - conn->ta_start_time >= > lu_status->timeout)) { > > -- ret = talloc_asprintf(ctx, "%s\nDomain %u: > %ld s", > > -+ ret = talloc_asprintf(ctx, "%s\nDomain %u: > %jd s", > > - ret ? : "Domains with > long running transactions:", > > - conn->id, > > -- now - > conn->ta_start_time); > > -+ (intmax_t)now - > conn->ta_start_time); > > - } > > - } > > - > > diff --git a/recipes-extended/xen/xen-tools_git.bb < > http://xen-tools_git.bb> b/recipes-extended/xen/xen-tools_git.bb < > http://xen-tools_git.bb> > > index 8397178e8d4b..b443b13eeab3 100644 > > --- a/recipes-extended/xen/xen-tools_git.bb <http://xen-tools_git.bb > > > > +++ b/recipes-extended/xen/xen-tools_git.bb <http://xen-tools_git.bb > > > > @@ -1,7 +1,7 @@ > > # master status on 2023-05-26 > > SRCREV ?= "03cf7ca23e0e876075954c558485b267b7d02406" > > > > -XEN_REL ?= "4.18" > > +XEN_REL ?= "4.19" > > XEN_BRANCH ?= "master" > > > > SRC_URI = " \ > > -- > > 2.25.1 > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8883): https://lists.yoctoproject.org/g/meta-virtualization/message/8883 Mute This Topic: https://lists.yoctoproject.org/mt/108390744/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
