Earlier today I uploaded what I expect to be the last significant
packaging work for LXD that I will perform. The snapshot version of LXD
appears to work correctly in sid, and I only anticipate making small
tweaks if needed in advance of the trixie release next year.
Referring to my email on 2
Thanks, Free and Stéphane. Based on your comments, I think the best
path forward will be to keep LXD packaging as-is for the trixie
release, although its version will be stuck at the 5.0 LTS snapshot
unless someone else steps in to further update it. I don't want to try
to do any potentially tric
Hi Matthias
On 2023/12/14 00:19, Mathias Gibbens wrote:
Other thoughts or opinions?
Thanks for the details and thoughtful synopsis!
Yep, there's a bunch of things to still figure out, and a lot can still
happen in the next year, but in general it all seems like a general good
direction f
Currently lxd-to-incus looks for the existing running LXD daemon to
validate the user configuration ahead of migrating the data to Incus,
that's why we need the LXD Go package for it, we actively interact with the
LXD API before shutting it down for the migration.
So if you want to get rid of LXD
Hello Mathias,
thanks for the thoughtful write-up.
I'm pretty much on board with everything you said.
The only detail I'm not totally sure about is whether it would actually
be beneficial to have trixie ship LXD 5.0 (at commit ^1364ae4). It's
true that it'd be an out-of-date LXD, but it might be
Control: retitle -1 LXD licensing changes and future for Debian packaging
Control: severity -1 important
Hi Jonathan,
(Adding Free and Stéphane for their awareness)
Free and I have been working on getting Incus packaged for Debian
(see ITP#1042989 and https://wiki.debian.org/Incus). Free's g
6 matches
Mail list logo
