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 the two bug lists, and try to work on the Salsa list first to get it empty: https://salsa.debian.org/xen-team/debian-xen/issues Diziet will look over the Salsa issues esp. issue 8 (xentoolcore). We intend to hold a "virtual bug squashing party" to work on these issues, on Monday the 10th of September Knorrie will prepare an agenda and post it here. Diziet will then send a mail to dda. Re this list, which is currently on the alioth continuity plan: We want to move to a list.d.o list. Knorrie will request one. Ian. -- Ian Jackson <ijackson at chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Hi team, On 08/22/2018 03:56 PM, Ian Jackson wrote:> Knorrie and I just discussed our plans for sid and buster, on the > phone. Here's my notes of the discussion.Yeah, that was quite a bit more efficient than typing a lot of text on IRC.> Plan is to upload Knorrie's 4.11 packages to experimental, to make > them more public, while we fix the bugs in them.This can be done from tag debian/4.11.1_pre+1.733450b39b-1_exp1 (which is right now the same as the master branch).> 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 the two bug lists, and try to work on the > Salsa list first to get it empty: > https://salsa.debian.org/xen-team/debian-xen/issuesYes, I put things in there because I can't open bugs in the BTS for a package that does not exist yet...> Diziet will look over the Salsa issues esp. issue 8 (xentoolcore).I will revert the borking xentoolcore fix in a yolo branch and cause the original ftbfs to happen again and add that info to the issue.> We intend to hold a "virtual bug squashing party" to work on these > issues, on Monday the 10th of September Knorrie will prepare an > agenda and post it here. Diziet will then send a mail to dda.The end goal of the day will be to have the thing in a shape that can transition from experimental to unstable. Besides the xentoolcore issue, which is causing actual breakage now (well, in my 4.10 -> 4.11 upgrades that I'm in now myself), it's mainly the lintian things that I could identify. I added all lintian warnings and errors to issues. Maybe some of them are irrelevant, some of them are relevant. At this point, it's important to get the 4.11 packages into sid/buster so that users can start playing around with them, half a year before we're gonna have a new Debian stable. Upstream announced that the 4.12 release will be around the time that Debian Buster releases out of deep freeze, so unless weird things happen, I guess Buster has to ship 4.11-stable, which is the thing we're looking at *right now*. By the way, at work, I use the packages on Stretch by just rebuilding them in stretch pbuilder. So, for whoever wants to use this on Stretch, I'm paying attention to the thing being able to rebuild on it all the time.> Re this list, which is currently on the alioth continuity plan: We > want to move to a list.d.o list. Knorrie will request one.https://www.debian.org/MailingLists/HOWTO_start_list I will write the draft which should go into the bts wishlist bug report against the lists.debian.org pseudo-package, and post it here on our list for review. I think it makes sense to have Ian file it because I'm not a DD or DM. Yay, Knorrie
> On Aug 22, 2018, at 6:29 PM, Hans van Kranenburg <hans at knorrie.org> wrote: > > By the way, at work, I use the packages on Stretch by just rebuilding > them in stretch pbuilder. So, for whoever wants to use this on Stretch, > I'm paying attention to the thing being able to rebuild on it all the time.Given this, it would be cool to plan to backport xen 4.11 to stretch-backports once it makes it to buster. Stephen
On 08/22/2018 03:56 PM, Ian Jackson wrote:> > Diziet will look over the Salsa issues esp. issue 8 (xentoolcore).See knorrie/toolcore branch with ea2334dfe0 reverted, https://salsa.debian.org/xen-team/debian-xen/issues/8#note_39872 This is what happens, and I have no idea about how to deal with it. Knorrie
Hans van Kranenburg writes ("Re: Plans for
buster"):> This can be done from tag debian/4.11.1_pre+1.733450b39b-1_exp1 (which
> is right now the same as the master branch).
Thanks for doing all this work. I have just sent it to experimental.
I did some reviewing and diffing. I have some comments, or, at least,
things I noticed. None of them were IMO blockers for experimental.
Hence the upload. (But I think some of them are blockers for sid.)
* libxtoolcore has the wrong soname. Upstream it is 1. IDK if this
should have its own deb. Putting it in the libxenstore one is
probably tolerable. Hans, I know you know there's a problem here.
I haven't investigated what happens with that patch reverted, yet.
* I don't understand why all the Linux module API stuff is needed.
Xen does not have modules. So VERSION_UPSTREAM, VERSION_BINNMU,
etc., are maybe not needed ?
* The patch to reintroduce xs_restrict should go upstream. I think
that, upstream, it would be a backport candidate, thus meaning
Debian wouldn't have to carry it. (And I'm a tools maintainer and a
stable maintainer upstream, so my initial opinion is fairly
predictive...)
* I don't think renaming the patches was particularly helpful. It
generates noise in diffs. (But please don't rename them back.)
* I noticed this in debian/rules:
SHELL := sh -e
Does that actually work ? Colour me surprised. I wonder why it
isn't done more widely.
* There were a bunch of complaints from lintian.
* I followed the instructions in debian/README.source.md and
my first attempt to build a source package failed [1]. Using
dpkg-buildpackage -uc -ui -us -B
instead worked. This should be documented in README.source.md.
If we don't change the whole git workflow; I'm afraid I'm going
to reopen that, but that'll be a separate message.
Thanks,
Ian
[1]
zealot:xen> dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: error: unwanted binary file:
debian/lib/python/debian_linux/__pycache__/gencontrol.cpython-35.pyc
dpkg-source: error: unwanted binary file:
debian/lib/python/debian_linux/__pycache__/utils.cpython-35.pyc
dpkg-source: error: unwanted binary file:
debian/lib/python/debian_linux/__pycache__/__init__.cpython-35.pyc
dpkg-source: error: unwanted binary file:
debian/lib/python/debian_linux/__pycache__/debian.cpython-35.pyc
dpkg-source: error: unwanted binary file:
debian/lib/python/debian_linux/__pycache__/config.cpython-35.pyc
dpkg-source: error: unwanted binary file:
debian/lib/python/debian_xen/__pycache__/__init__.cpython-35.pyc
dpkg-source: error: unwanted binary file:
debian/lib/python/debian_xen/__pycache__/debian.cpython-35.pyc
dpkg-source: error: detected 7 unwanted binary files (add them in
debian/source/include-binaries to allow their inclusion).
zealot:xen>
--
Ian Jackson <ijackson at chiark.greenend.org.uk> These opinions are my
own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.