similar to: Xen BOF at Debconf 18

Hans van Kranenburg writes ("[PATCH 06/13] sysconfig.xencommons.in: Strip and debianize"): > Strip all options that are for stuff we don't ship, which is 1) > xenstored as stubdom and 2) xenbackendd, which seems to be dead code > anyway. [1] > > It seems useful to give the user the option to revert to xenstored > instead of the default oxenstored if they really

Hi. I was wanting an initial opinion from the Release Team, about the Xen packages. Currently they are in bad shape in stretch and I intend to fix them ASAP. The question is whether I should move to Xen 4.7, or Xen 4.8. Xen 4.8 is currently at RC2 and seems in pretty good shape. I think it's more probable than not that we'll have Xen 4.8.0 by the Debian freeze date, but this is by no

Hans van Kranenburg writes ("[PATCH 09/13] xen init script: move init_dom0 into xenstored start"): > This little xen-init-dom0 program is present in both our 4.8 and 4.11 > packages, so there's no need to keep the if else code. Also, it only > makes sense to run it after starting xenstored, and not all other times > start is called. I think xen-init-dom0 is not in jessie

I have now finished totally rewriting the Xen package in Debian, from scratch. Amazingly as soon as I got a package which was lintian-clean and would install, it worked first time ! I have generated 18 patches to go upstream which I have sent to xen-devel. There are two more, xenstore ABI patches, which need a bit of tidying up. There is still room for improvement but it is now clearly ready

Initially out there as #965245. I strongly prefer to build ARM64 packages on non-ARM systems. Something about my main build machine having twice the cores and twice the clock speed. As such after many builds I've managed to generate a set of patches which appear to mostly function to get functioning cross-builds of Xen. These are NOT a 100% solution. Some packaging hacks were needed. In

Knorrie and I just discussed our plans for sid and buster, on the phone. Here's my notes of the discussion. Plan is to upload Knorrie's 4.11 packages to experimental, to make them more public, while we fix the bugs in them. There's a list of Salsa issues and the BTS bugs list. This duplication is not ideal. We agreed that new things should go to the BTS. For now we'll keep

Hans van Kranenburg writes ("[PATCH 08/13] xen init script: rewrite xenstored start logic"): > -XENSTORED="$ROOT"/bin/xenstored > +# In /etc/default/xen, the user can set XENSTORED, which has to be either > +# 'xenstored' or 'oxenstored'. In here, we add the version specific path. > +if [ -n "$XENSTORED" ]; then > +

Hi Maximilian, there is an ocaml stack rebuild[1] at them moment, where xen is a part of. So please upload to experimental. Thanks! Thorsten [1] https://release.debian.org/transitions/html/ocaml.html === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns.

On 19/10/16 16:54, Ian Jackson wrote: > Ian Jackson writes ("Xen in stretch - 4.7 or 4.8 ?"): >> Hi. I was wanting an initial opinion from the Release Team, about the >> Xen packages. Currently they are in bad shape in stretch and I intend >> to fix them ASAP. >> >> The question is whether I should move to Xen 4.7, or Xen 4.8. > > I just asked

xen source: lintian output: 'license-problem-gfdl-invariants stubdom/grub.patches/00cvs invariant part is: with no invariant sections, with the front-cover texts being a gnu manual, and with the back-cover texts as in (a) below', automatically rejected package. xen source: If you have a good reason, you may override this lintian tag. xen-utils-4.11: lintian output:

Hi Ian, On 05-02-2023 14:06, Ian Jackson wrote: > Sorry again for being an idiot, but where should we have checked, to > avoid such a mistake in the future ? I thought this kind of thing > would appear on tracker but > https://tracker.debian.org/pkg/xen > doesn't show it now. ocaml is a bit weird, it has a permanent tracker:

Hi all, Thanks for sending this update Hans. I too am interested in helping out with xen packaging. I am trying to dig into the dpkg-shlibdeps issues - I built it successfully on one box but haven?t been able to reproduce. Either way, I will plan to hang around in IRC to help where I can. Stephen > On Jan 9, 2018, at 4:05 PM, Hans van Kranenburg <hans at knorrie.org> wrote: >

Elliott Mitchell writes ("[PATCH 12/12] Partially revert "Cross-compilation fixes.""): > This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7. Wow, that is an upsteam commit from 2005. However, I would like some kind of explanation. Is it in fact now false that | # These don't cross-compile ? Should this patch go upstream ? Ian. -- Ian Jackson

Control: retitle -1 max grant frames problem (domu freeze with linux-image-4.9.0-4-amd64) Control: severity -1 important Control: reassign -1 src:xen 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u9 Just gardening here. (i) Bug title should mention grant frames. (ii) This does not affect all use cases and is not, IMO, RC. Although we should certainly see if we can improve it. (iii) Britney is confused

(*Really* switching to my personal address not because I'm not doing work for Citrix, but because the corporate email is not working properly. Sigh. Also, email updated a bit.) Ian Jackson writes ("Re: Updated Xen packages for XSA 216..225"): > Ian Jackson writes ("Re: Updated Xen packages for XSA 216..225"): > > Hi. I was away and am now back. There are a lot

Dear Security Team, I have prepared a new upload addressing a number of open security issues in Xen. Due to the complexity of the patches that address XSA-273 [0] the packages have been built from upstream's staging-4.8 / staging-4.10 branch again as recommended in that advisory. Commits on those branches are restricted to those that address the following XSAs (cf. [1]): - XSA-273

The contents are the wip.testme branch currently on salsa. I combined the wip.initscript and wip.oxenstored into this and added more things today. I think this is pretty gtg and it's smoke tested (in several cases by scping files around instead of doing package build), so it needs a final extra review and test round before putting it in master branch (which I don't want to force push). I

I'm just dumping all I got in here, after initial feedback we can see how to organize todo's around it. tl;dr: * Does not upgrade cleanly from 4.8 packages, so we have to prevent this from entering testing until we fix that. * Live migration is broken, explodes with memory allocation errors. ---- >8 ---- 1. Build packages * I have built salsa/master using pbuilder targeting sid.

On 20 August 2014 00:24, Gerolf Hoflehner <ghoflehner at apple.com> wrote: > My experience from leading BOFs at other conferences is more talk than action. So I suggest a different setup for this topic: how about having a working group meeting with participants who can commit time to work on this topic? Mine too, but in this case I have to say it wasn't at all what happened. It

Dear community, We are trying to setup a BoF ( Raising Next Generation of LLVM Developers, http://sched.co/8Yzs). In our academic-oriented environments the main work force is students: undergrads, grads or PhD (rarely postdocs). Often we have limited time to bring somebody up to speed and we have to it in a productive and motivating for both parties way. I believe most of you had