Bug#1089033: xen: Please package xen version 4.19

[Santiago Ruano Rincón]

Source: xen
Severity: normal
User: debian-***@lists.debian.org
Usertags: upstream-trixie
X-Debbugs-Cc: debian-***@lists.debian.org

Dear xen maintainers,

Testing (trixie) currently ships xen 4.17, which, according to the
upstream support matrix [x], will get security support until 2025-12-12.
The latest upstream release (4.19) will get security support until
2027-07-29. I believe it would be easier to provide security updates for
trixie users if 4.19 is packaged in testing.

If you need or want help packaging this new upstream version, please
don't hesitate to speak up. Someone from the LTS team, may be interested
in contributing (CC'ing debian-lts).

[x] https://xenbits.xen.org/docs/unstable/support-matrix.html

Best regards,

-- Santiago, for the LTS Team.

[Sean Whitton]

Hello,

Post by Santiago Ruano Rincón
Source: xen
Severity: normal
Usertags: upstream-trixie
Dear xen maintainers,
Testing (trixie) currently ships xen 4.17, which, according to the
upstream support matrix [x], will get security support until 2025-12-12.
The latest upstream release (4.19) will get security support until
2027-07-29. I believe it would be easier to provide security updates for
trixie users if 4.19 is packaged in testing.
If you need or want help packaging this new upstream version, please
don't hesitate to speak up. Someone from the LTS team, may be interested
in contributing (CC'ing debian-lts).

As I'm familiar with the git-debrebase workflow that Xen uses in Debian,
I might be well-placed to help; on the other hand, I'm less experienced
with packages that require special booting arrangements to test they are
working.

[Hans van Kranenburg]

Hi!

Thanks for reaching out.

Post by Sean Whitton
Hello,

Post by Santiago Ruano Rincón
Source: xen
Severity: normal
Usertags: upstream-trixie
Dear xen maintainers,
Testing (trixie) currently ships xen 4.17, which, according to the
upstream support matrix [x], will get security support until 2025-12-12.
The latest upstream release (4.19) will get security support until
2027-07-29. I believe it would be easier to provide security updates for
trixie users if 4.19 is packaged in testing.
If you need or want help packaging this new upstream version, please
don't hesitate to speak up. Someone from the LTS team, may be interested
in contributing (CC'ing debian-lts).

As I'm familiar with the git-debrebase workflow that Xen uses in Debian,
I might be well-placed to help; on the other hand, I'm less experienced
with packages that require special booting arrangements to test they are
working.

I'm not sure about the official plans or the current state, but
https://salsa.debian.org/xen-team/debian-xen/-/commits/myx/wip/experimental/?ref_type=heads

Yes, we need some assistance.

The situation regarding the packages is:
* We have a Xen 4.19 package ready, that has been tested.
* ==> We need a sponsor to upload it to experimental as NEW <==
* We can then prepare an up-to-date 4.19 for unstable.
* And then... we can again continue doing the 4.17 (security-)updates
for stable.

The current situation regarding the Debian Xen team is:
* Currently that's Maximilian and me. (I'm a DM)
* We're a dedicated team, we do manage, but we're also not enormously
high on excess bandwidth. I mean, we can't do a lot of the 'nice to haves'.
* We have established a stable workflow with great checklists in the
last few years.
* We always try to work together, mainly for quality reasons, to
continuously double-check what we're doing before we ship it, but also
of course because it's more fun to do things together than on your own.

But, there are single points of failure, as can already be spotted in
the above. I myself have been less available for personal reasons in the
last months (Hans says yes, life says no, for who recognizes such a
situation), and we were not really prepared yet for something like that
happening.

In general, what we could really use for assistance is a bit of a safety
net for certain situations. Like, a few (DD) people who we know and who
know about us and what we do, and who we can contact if needed, and who
can help with various topics, like sponsoring uploads if needed, help
with packaging tooling, navigating non-trivial package transitions,
complex makefile/build/library-dependency/etc stuff...

By the way, big thanks to the Team Security (Cc), especially Moritz and
Carnil, who already are more than a great help with the security update
workflow!

We can further discuss here, or interactively in #debian-xen on OFTC.
I'm going for lunch break now and will be on IRC.

Thanks,
Hans

[Sean Whitton]

Hello,

Post by Hans van Kranenburg
Yes, we need some assistance.

Thank you for the write-up. Santiago, maybe we should add a link to
this thread to packages.yml, or something like that? What do you think?

Post by Hans van Kranenburg
* We have a Xen 4.19 package ready, that has been tested.
* ==> We need a sponsor to upload it to experimental as NEW <==
* We can then prepare an up-to-date 4.19 for unstable.
* And then... we can again continue doing the 4.17 (security-)updates
for stable.

Cool, I will sponsor the upload, can you confirm the repository and
branch that you consider ready-to-go ?

Post by Hans van Kranenburg
* Currently that's Maximilian and me. (I'm a DM)
* We're a dedicated team, we do manage, but we're also not enormously
high on excess bandwidth. I mean, we can't do a lot of the 'nice to haves'.

Describes plenty of teams in Debian.
I like to think it means you don't spend time on things that are
not-really-nice-to-have-but-feel-like-they-are :)

Post by Hans van Kranenburg
In general, what we could really use for assistance is a bit of a safety
net for certain situations. Like, a few (DD) people who we know and who
know about us and what we do, and who we can contact if needed, and who
can help with various topics, like sponsoring uploads if needed, help
with packaging tooling, navigating non-trivial package transitions,
complex makefile/build/library-dependency/etc stuff...

When it's a matter of these major version transitions and you are close
to running out of time for the next stable release of Debian, I think
you could always get in touch with debian-***@lists.d.o and there is a
good chance someone is available to help (me in this case).

[Maximilian Engelhardt]

Hi everybody,

I'm sorry for replying late, this week was quite busy for me.

Post by Sean Whitton

Post by Hans van Kranenburg
* We have a Xen 4.19 package ready, that has been tested.
* ==> We need a sponsor to upload it to experimental as NEW <==
* We can then prepare an up-to-date 4.19 for unstable.
* And then... we can again continue doing the 4.17 (security-)updates
for stable.

Cool, I will sponsor the upload, can you confirm the repository and
branch that you consider ready-to-go ?

I have been preparing first xen 4.18 and later xen 4.19 some time ago in the
hope to get it into unstable and testing. However this was somehow stalled by
waiting for review and approval from Hans. And also me failing to search for
help in other places to get things moving, after nothing happened for a long
time.

In agreement with Hans I have now finalized my current branch and put it
directly in our experimental branch:

https://salsa.debian.org/xen-team/debian-xen/-/tree/experimental
(commit 0d23f70837fcd59f450dd281c224d3a06d923a09)

The current packaging state is a few month old, but I guess it's best to get
it into the Debian archive pretty soon. We can then prepare an update to the
latest upstream, which should not be too much work.

I did some tests to make sure what is currently in the experimental branch is
working well. This includes:

* compiling in an updated unstable environment and check it compiles fine
* check lintian output for any severe issues with the package
* run the xen hypervisor in a qemu vm and verify xen vm creation is working
* Compile a backport to bookworm which I have been running for some month on a
local test system using pci-passthrough without and problems

To my knowledge the following would be the next steps:

* upload xen 4.19 to experimental to pass the new queue.
* update to latest upstream and upload to unstable when suitable.
The upload to unstable will also trigger a small transition, but usually
just rebuilding the affected packages (kexec-tools, libvirt, qemu and
collectd) is sufficient.
* monitor there are now issues preventing it from migrating to testing

Once this has happened we can also look into updating xen in stable again.

Thanks,
Maxi

[Sean Whitton]

Hello,

Uploaded to NEW. Please 'dgit fetch' my
debian/4.19.0+14-g0918434e0f-1_exp1 tag and push it to your repository
on salsa. Thanks!

[Hans van Kranenburg]

Hi Sean,

Post by Sean Whitton
Uploaded to NEW. Please 'dgit fetch' my
debian/4.19.0+14-g0918434e0f-1_exp1 tag and push it to your repository
on salsa. Thanks!

Done.

We'd like to request an additional sponsored upload, since we're again
touching the binary packages list...

https://salsa.debian.org/xen-team/debian-xen/-/commits/experimental

I already tried uploading it, but got a REJECTED back. I couldn't really
find definitive information about when exactly a binary package name
would trigger NEW if it was already in the archive and related to the
same source package, so I gave it a try to find out. So, the dgit tags
etc do already exist. I don't know if this is a problem.

We have a FTBFS on armhf, and while investigating, we found out that
we're not going to be able to fix that. Since the armhf build was
already unusable by default for years, we're now deciding to pull the
plug on the life support of the already comatose patient.

Also see the commits.

And, we're also uncrufting the remainder of the t64 stuff, because for
the libraries involved it already did not make sense to begin with. And
if it had made sense, it could actually have introduced upgrade problems
for our users, since these are the libraries that users would also be
using then rebooting back to the Bookworm Xen 4.17 for any reason after
they upgrade to Trixie. But, in any case, we don't even have 32-bit
archs left currently, so that would only have applied to armhf which no
one is running with Debian Xen packages already. ¯\_(ツ)_/¯

Regards,
Hans

[Sean Whitton]

Hello,

Post by Hans van Kranenburg
Hi Sean,

Post by Sean Whitton
Uploaded to NEW. Please 'dgit fetch' my
debian/4.19.0+14-g0918434e0f-1_exp1 tag and push it to your repository
on salsa. Thanks!

Done.
We'd like to request an additional sponsored upload, since we're again
touching the binary packages list...
https://salsa.debian.org/xen-team/debian-xen/-/commits/experimental
I already tried uploading it, but got a REJECTED back. I couldn't really
find definitive information about when exactly a binary package name
would trigger NEW if it was already in the archive and related to the
same source package, so I gave it a try to find out. So, the dgit tags
etc do already exist. I don't know if this is a problem.

Not a problem, you just need to add a new changelog entry and bump the
version number. If you'd like to give me push access to the repository,
it might be easiest for me to do it. Whichever.

[Hans van Kranenburg]

Hi,

Post by Sean Whitton
Hello,

Post by Hans van Kranenburg
Hi Sean,

Post by Sean Whitton
Uploaded to NEW. Please 'dgit fetch' my
debian/4.19.0+14-g0918434e0f-1_exp1 tag and push it to your repository
on salsa. Thanks!

Done.
We'd like to request an additional sponsored upload, since we're again
touching the binary packages list...
https://salsa.debian.org/xen-team/debian-xen/-/commits/experimental
I already tried uploading it, but got a REJECTED back. I couldn't really
find definitive information about when exactly a binary package name
would trigger NEW if it was already in the archive and related to the
same source package, so I gave it a try to find out. So, the dgit tags
etc do already exist. I don't know if this is a problem.

Not a problem, you just need to add a new changelog entry and bump the
version number. If you'd like to give me push access to the repository,
it might be easiest for me to do it. Whichever.

4.19.1-1~exp3 is ready for upload:

https://salsa.debian.org/xen-team/debian-xen/-/commits/experimental

I added you to the members on Salsa. That's a good idea and convenient
for all of us.

Thanks a lot,
Hans

[Sean Whitton]

Hello,

Uploaded!

[Santiago Ruano Rincón]

Thanks a lot to Hans, Maximilian and Sean!

Post by Sean Whitton
Hello,

Post by Hans van Kranenburg
Yes, we need some assistance.

Thank you for the write-up. Santiago, maybe we should add a link to
this thread to packages.yml, or something like that? What do you think?

Why not, but... xen security support in bullseye last year (exactly on
2023-09-30, a little more than two years after the bullseye release):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053246, and it was
similar for buster.
Of course, part of the goal of my initial bug report was to improve the
xen security support for trixie in that sense. The Xen packaging team
has stated in #1053246 that they were not in a position to continue
supporting xen after the upstream EOL. (And one of the next steps is to
look again for external help). My point is that the lts-team's
package.yml is probably not the best place to document the xen team'
needs, because xen is out of our current tooling radar.

Adding it there doesn't harm, but I wonder if that is the best place if
the goal is to monitor packages where the LTS team could help on
unstable/testing. Further discussion can be done at the "Explore ways to
figure out which packages in unstable could use help" issue:
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/71.

[...]

Post by Sean Whitton

Post by Hans van Kranenburg
In general, what we could really use for assistance is a bit of a safety
net for certain situations. Like, a few (DD) people who we know and who
know about us and what we do, and who we can contact if needed, and who
can help with various topics, like sponsoring uploads if needed, help
with packaging tooling, navigating non-trivial package transitions,
complex makefile/build/library-dependency/etc stuff...

When it's a matter of these major version transitions and you are close
to running out of time for the next stable release of Debian, I think
good chance someone is available to help (me in this case).

+1

Cheers,

-- Santiago

[Sean Whitton]

Hello,

Post by Santiago Ruano Rincón
Why not, but... xen security support in bullseye last year (exactly on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053246, and it was
similar for buster.
Of course, part of the goal of my initial bug report was to improve the
xen security support for trixie in that sense. The Xen packaging team
has stated in #1053246 that they were not in a position to continue
supporting xen after the upstream EOL. (And one of the next steps is to
look again for external help). My point is that the lts-team's
package.yml is probably not the best place to document the xen team'
needs, because xen is out of our current tooling radar.
Adding it there doesn't harm, but I wonder if that is the best place if
the goal is to monitor packages where the LTS team could help on
unstable/testing. Further discussion can be done at the "Explore ways to
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/71.

I'll drop a note there, thanks.