similar to: xen_4.17.0+24-g2f8851c37f-1_multi.changes REJECTED

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:

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

I am going to submit a proposal for a Xen BOF at DC18. Here is my first cut at a draft abstract: Title: Xen in Debian BoF Format: workshop with 25 min slot The Xen packages in Debian are in need of some work, including some tidying up, upstreaming of some Makefile patches, and updating to new versions. There is a large outstanding bug list. Also with the demise of Alioth and the

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

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:

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

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: >

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 > +

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

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

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

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.

Hans van Kranenburg writes ("Re: git workflow, redux"): > On 08/23/2018 08:07 PM, Ian Jackson wrote: > > I think git-debrebase is going to be easier for all these things than > > the current approach. > > Ok, let's try it! Thanks a lot for doing the above writeup. Great, thanks. (I hope it's OK that I have snipped most of your responses to the discussion,

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

Do you receive RDS objects from unknown (untrusted) sources? ?? If not - the security issue is a non-issue as I understand it. On Thu, 16 May 2024, 16:21 Vega, Ann (she/her/hers) via R-help, < r-help at r-project.org> wrote: > I help to coordinate the USEPA's R user group. We have over 500 members > and our security officer has required us to update to R version 4.4.0 >

Hi Ian, team, In the week of Feb 23 (time flies!:), we had a very productive day \o/ working on the stretch security/stable package and some irc discussions in oftc #debian-xen which ended with an open end. Ian, you were a bit surprised that 1) my debian-xen repo started with an import of a 4.8 package 2) it was not a git-pbuilder style repo with upstream source included, and asked me to at

I help to coordinate the USEPA's R user group. We have over 500 members and our security officer has required us to update to R version 4.4.0 because of the security vulnerability to versions prior. However, we cannot download the patched version because it does not have a signed certificate and Microsoft Defender won't allow us to install it. Most of our users rely on the RStudio