On Thu, Aug 19, 2021 at 05:23:26PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("Re: preparations for 4.15.1 and 4.13.4"):
> > Can we backport support of QEMU 6.0 to Xen 4.15? I'm pretty sure
> > distributions are going to want to use the latest QEMU and lat
Am Thu, 19 Aug 2021 17:23:26 +0100
schrieb Ian Jackson :
> Anthony PERARD writes ("Re: preparations for 4.15.1 and 4.13.4"):
> > Also, Olaf want them to be backported to 4.14, see
> > <20210629095952.7b0b94c1.o...@aepfle.de>
> I'm unsure about this.
Am Thu, 19 Aug 2021 17:46:28 +0100
schrieb Ian Jackson :
> I would be happy to take fixes like these for stable branches. I
> tried a git cherry-pick but it didn't apply. Would you like to supply
> backports ?
This script worked for me in staging-4.13:
set -ex
git cherry-pick -ex e54c433adf01a
On 19.08.2021 18:43, Ian Jackson wrote:
> Jan Beulich writes ("preparations for 4.15.1 and 4.13.4"):
>> Ian: I did take the liberty to backport Anthony's
>>
>> 5d3e4ebb5c71 libs/foreignmemory: Fix osdep_xenforeignmemory_map prototype
>
> Thanks.
>
>> Beyond this I'd like the following to be consi
Ian Jackson writes ("Re: preparations for 4.15.1 and 4.13.4 [and 1 more
messages]"):
> I thought of a better way to do this. See below for proposed patch to
> xen.git#staging.
We discussed this on IRC, and I'm going to drop this patch.
Ian.
18:00 <@andyhhp> I'
get bumped on
first new addition.
Otherwise, if there is no addition between now and the 4.16 release,
then the 4.16 build will produce a libfoo.so.1.4 with 1.3's effective ABI.
The same would be true in general for every stable library we didn't
modify in a specific release cycle.
&
Ian Jackson writes ("Re: preparations for 4.15.1 and 4.13.4 [and 1 more
messages]"):
> Jan Beulich writes ("preparations for 4.15.1 and 4.13.4"):
> > The ABI called VERS_1.2 must be identical on all older branches to avoid
> > binary problems when rebuilding a p
Jan Beulich writes ("Re: preparations for 4.15.1 and 4.13.4"):
> On 15.07.2021 09:58, Jan Beulich wrote:
> > Beyond this I'd like the following to be considered:
> >
> > 6409210a5f51 libxencall: osdep_hypercall() should return long
> > bef64f2c0019
Olaf Hering writes ("Re: preparations for 4.15.1 and 4.13.4"):
> Am Thu, 15 Jul 2021 09:58:24 +0200
> schrieb Jan Beulich :
>
> > Please point out backports you find missing from the respective staging
> > branches, but which you consider relevant.
>
> Depe
because of
7ffbed8681a0
libxencall: drop bogus mentioning of xencall6()
which is fine, since that symbol didn't exist in any version.
So I propose to bump xencall to 1.4 in staging, to make sure we don't
break the ABI for 1.3 by mistake.
Andrew Cooper writes ("Re: preparations
Anthony PERARD writes ("Re: preparations for 4.15.1 and 4.13.4"):
> Can we backport support of QEMU 6.0 to Xen 4.15? I'm pretty sure
> distributions are going to want to use the latest QEMU and latest Xen,
> without needed to build two different QEMU binaries.
I think t
Ian,
On 15.07.2021 09:58, Jan Beulich wrote:
> Beyond this I'd like the following to be considered:
>
> 6409210a5f51 libxencall: osdep_hypercall() should return long
> bef64f2c0019 libxencall: introduce variant of xencall2() returning long
> 01a2d001dea2 libxencall: Bump SONAME following new func
On Fri, 16 Jul 2021, Julien Grall wrote:
> On 15/07/2021 08:58, Jan Beulich wrote:
> > All,
>
> Hi Jan & Stefano,
>
>
> > the releases are due in a couple of weeks time (and 4.14.3 is
> > supposed to follow another few weeks later). Please point out backports
> > you find missing from the respec
On 15/07/2021 08:58, Jan Beulich wrote:
All,
Hi Jan & Stefano,
the releases are due in a couple of weeks time (and 4.14.3 is
supposed to follow another few weeks later). Please point out backports
you find missing from the respective staging branches, but which you
consider relevant.
Please
On 15.07.2021 19:16, Andrew Cooper wrote:
> On 15/07/2021 08:58, Jan Beulich wrote:
>> Beyond this I'd like the following to be considered:
>>
>> 6409210a5f51 libxencall: osdep_hypercall() should return long
>> bef64f2c0019 libxencall: introduce variant of xencall2() returning long
>> 01a2d001dea2
On 15/07/2021 08:58, Jan Beulich wrote:
> Beyond this I'd like the following to be considered:
>
> 6409210a5f51 libxencall: osdep_hypercall() should return long
> bef64f2c0019 libxencall: introduce variant of xencall2() returning long
> 01a2d001dea2 libxencall: Bump SONAME following new functionali
On 15.07.2021 16:11, Olaf Hering wrote:
> Am Thu, 15 Jul 2021 09:58:24 +0200
> schrieb Jan Beulich :
>
>> Please point out backports you find missing from the respective staging
>> branches, but which you consider relevant.
>
> Depending on how green the CI is supposed to be:
>
> 76416c459c lib
Am Thu, 15 Jul 2021 09:58:24 +0200
schrieb Jan Beulich :
> Please point out backports you find missing from the respective staging
> branches, but which you consider relevant.
Depending on how green the CI is supposed to be:
76416c459c libfsimage: fix parentheses in macro parameters
e54c433adf
On 15.07.2021 12:58, Andrew Cooper wrote:
> On 15/07/2021 08:58, Jan Beulich wrote:
>> All,
>>
>> the releases are due in a couple of weeks time (and 4.14.3 is
>> supposed to follow another few weeks later). Please point out backports
>> you find missing from the respective staging branches, but wh
On 15/07/2021 08:58, Jan Beulich wrote:
> All,
>
> the releases are due in a couple of weeks time (and 4.14.3 is
> supposed to follow another few weeks later). Please point out backports
> you find missing from the respective staging branches, but which you
> consider relevant.
I've got a queue of
Can we backport support of QEMU 6.0 to Xen 4.15? I'm pretty sure
distributions are going to want to use the latest QEMU and latest Xen,
without needed to build two different QEMU binaries.
[XEN PATCH v2 0/8] Fix libxl with QEMU 6.0 + remove some more deprecated usages.
<20210511092810.13759-1-anth
Andrew,
On 15.07.2021 09:58, Jan Beulich wrote:
> the releases are due in a couple of weeks time (and 4.14.3 is
> supposed to follow another few weeks later). Please point out backports
> you find missing from the respective staging branches, but which you
> consider relevant.
>
> Please note tha
22 matches
Mail list logo