Bug#768073: [pkg-lxc-devel] Bug#768073: ITP: lxd - The Linux Container Daemon

[Pierre-Elliott Bécue]

Mathias Gibbens  wrote on 06/02/2022 at 03:38:03+0100:

> [[PGP Signed Part:No public key for 29EEE2D6ECF442F9 created at 
> 2022-02-06T03:38:03+0100 using RSA]]
>   For those following this ITP, the end is in sight! I have whittled
> down the huge list of missing dependencies to just nine packages, all
> of which are ready for upload. They're just waiting on sponsorship
> and/or other dependencies to make it through into unstable.
>
>   The packaging work for LXD is also largely complete. The git repo is
> available on salsa [1], and I would invite interested parties to take a
> look and provide any feedback. This is the most complicated package
> I've created to date, so I'm sure there's room for improvement.

I can do the sponsorship, send me the list of things to review by mail!
:)

-- 
PEB


signature.asc
Description: PGP signature

Bug#768073: ITP: lxd - The Linux Container Daemon

[Mathias Gibbens]

  For those following this ITP, the end is in sight! I have whittled
down the huge list of missing dependencies to just nine packages, all
of which are ready for upload. They're just waiting on sponsorship
and/or other dependencies to make it through into unstable.

  The packaging work for LXD is also largely complete. The git repo is
available on salsa [1], and I would invite interested parties to take a
look and provide any feedback. This is the most complicated package
I've created to date, so I'm sure there's room for improvement.

Mathias

[1] -- https://salsa.debian.org/go-team/packages/lxd


signature.asc
Description: This is a digitally signed message part

Bug#768073: [pkg-lxc-devel] Bug#768073: ITP: lxd - The Linux Container Daemon

[Clément Hermann]

Hi,

On 08/01/2021 05:07, peylight wrote:
> Hi Dear Debian Developers,
> Can you check the 331th message of LXD packaging please:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768073#311
> 

Thanks for your interest in LXD packaging - and sorry for the late reply.

The issue with said package is that it doesn't follow Debian packaging
guidelines. We can't vendor all the deps like it's done here. Some
vendoring might be OK in very specific cases, but here we have to take
the long road.

The progress on packaging LXD deps is tracked in gobby.debian.org at
Teams/Go/lxd-deps-packaging.

An http export is here:
https://gobby.debian.org/export/Teams/Go/lxd-dep-packaging.

As you can see, there are still a lors of dependancies. I doubt we'll be
able to make this enter Debian before the soft freeze, but if enough
people want to help, that might still be possible.

Intested parties, please don't hesitate to just tag some entries in the
Gobby doc or ping me on IRC (nodens) to tell me what you're working on.

Cheers,

-- 
nodens

Bug#768073: ITP: lxd - The Linux Container Daemon

[peylight]

Hi Dear Debian Developers,
Can you check the 331th message of LXD packaging please:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768073#311

--
Best Regards,
peylight

Bug#768073: ITP: lxd - The Linux Container Daemon

[Piotr Iwaniuk]

Hello,

For the last few weeks I have been working on a Debian package for LXD 
after switching to Debian from Fedora where the package was available. I 
was targeting the stable release (buster). I added several workarounds 
to create deb packages from upstream released Golang source code. The 
end result was able to initialize LXD and create a container.


My debian directory is available here: 
. It is my first Debian package 
and it likely still has a lot of issues but may be it will useful.


--
Regards,
Piotr

Bug#768073: ITP: lxd - The Linux Container Daemon

[Nicola Tuveri]

On Fri, 23 Oct 2020 22:59:17 +0200 =?UTF-8?Q?Cl=c3=a9ment_Hermann?=
 wrote:
>
> That was indeed on the radar after discussions with upstream at FOSDEM
> and we were in the loop. Thanks for keeping the subscribers of this bug
> informed! (and sorry I didn't do it myself).
>
> And now, dqlite is actually in Debian:
> https://tracker.debian.org/pkg/dqlite (thanks Laszlo!).
>
> I'm happy to say I can now resume working on LXD deps and lxd itself.
>
> We might have a chance to see LXD in the next release after all! \o/
>
> Cheers,
>
>
> --
> nodens
>
>

This is great news indeed!

I saw you mentioned limited availability to work on packaging LXD, can
you give some estimate of how much work you think is left in light of
the latest developments and how long it could take to have
experimental packaging?


Cheers,

Nicola

Bug#768073: ITP: lxd - The Linux Container Daemon

[Clément Hermann]

Hi,

On 27/09/2020 20:23, Kurt Kremitzki wrote:
> Hello,
> 
> With the release of LXD 4.6 [1], it should now be a lot easier for it to be 
> brought to Debian:
> 
> "Dqlite changes
> 
> Shortly after LXD 4.5 was released, a major change was made to upstream 
> dqlite.
> 
> Rather than relying on our fork of sqlite3 which was adding some hooks used 
> to 
> intercept filesystem writes and replicating to other nodes, we are now using 
> a 
> different approach to get VFS access from a standard sqlite3.
> 
> While invisible to users, this should help packagers a fair bit by removing 
> two custom dependencies of LXD, that custom sqlite3 and libco.
> 
> LXD with dqlite can now use any standard sqlite3 of version 3.25 or higher."
> 
> [1] https://discuss.linuxcontainers.org/t/lxd-4-6-has-been-released/8981

That was indeed on the radar after discussions with upstream at FOSDEM
and we were in the loop. Thanks for keeping the subscribers of this bug
informed! (and sorry I didn't do it myself).

And now, dqlite is actually in Debian:
https://tracker.debian.org/pkg/dqlite (thanks Laszlo!).

I'm happy to say I can now resume working on LXD deps and lxd itself.

We might have a chance to see LXD in the next release after all! \o/

Cheers,


-- 
nodens

Bug#768073: ITP: lxd - The Linux Container Daemon

[Kurt Kremitzki]

Hello,

With the release of LXD 4.6 [1], it should now be a lot easier for it to be 
brought to Debian:

"Dqlite changes

Shortly after LXD 4.5 was released, a major change was made to upstream 
dqlite.

Rather than relying on our fork of sqlite3 which was adding some hooks used to 
intercept filesystem writes and replicating to other nodes, we are now using a 
different approach to get VFS access from a standard sqlite3.

While invisible to users, this should help packagers a fair bit by removing 
two custom dependencies of LXD, that custom sqlite3 and libco.

LXD with dqlite can now use any standard sqlite3 of version 3.25 or higher."

[1] https://discuss.linuxcontainers.org/t/lxd-4-6-has-been-released/8981

Bug#768073: ITP: lxd -- The Linux Container Daemon

[Harald Dunkel]

Its sad that Debian missed the train.


Regards
Harri

Bug#768073: ITP: lxd -- The Linux Container Daemon

[Clément Hermann]

Hi,

First, sorry for the late reply. A mail filter caught this message
before I had the chance to read it.

On 14/12/2018 12:15, Harald Dunkel wrote:
> Hi folks,
> 
> how good are chances to get LXD into Buster?

As much as it pains me to say so, not very good at the moment, with the
soft freeze coming up in February.

The biggest issue is, starting with lxd3, Canonical decided to implement
replication in sqlite, which is fine, but since they needed it soon and
know that it would take a while for inclusion, they rely on a patched
version of sqlite.

It doesn't affect Ubuntu since Ubuntu is actually using Snap now to
distribute even the packaged version of LXD, and there having a patched
version is fine, since it's only in the snap context. However, we can't
patch sqlite this way in Debian.

you can check the ITP on golang-github-canonicalltd-dqlite [1] for more
info on this discussion. Sadly it's stalled currently (and the bandwidth
I can use to work on this packaging is quite low at the moment).


[1] - https://bugs.debian.org/905068

Cheers,

-- 
nodens

Bug#768073: ITP: lxd -- The Linux Container Daemon

[Harald Dunkel]

Hi folks,

how good are chances to get LXD into Buster?


Regards
Harri

Bug#768073: ITP: lxd - The Linux Container Daemon

[Jonathan Dowland]

On Sun, May 27, 2018 at 04:01:28PM +0300, Alexander Gerasiov wrote:

Nope, they said that _feature_ releases will be available as snap
packages, but LTS (3.0 for now, and may be other in the future) will
be supported as deb packages.


It's moot, anyway: Debian will be packaging the source and building our
own binaries, not redistrubuting theirs.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#768073: ITP: lxd - The Linux Container Daemon

[Alexander Gerasiov]

Nope, they said that _feature_ releases will be available as snap
packages, but LTS (3.0 for now, and may be other in the future) will
be supported as deb packages.

-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: g...@cs.msu.su  WWW: http://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Bug#768073: ITP: lxd - The Linux Container Daemon

[Leon Klingele]

Seems like the LXD snap is the way to go.
From now on, non-security related updates to LXD on Ubuntu will no
longer be distributed through debs.

"""
LXD 3.1 will only be made available as a snap package. We will not be
uploading it as a deb to Ubuntu 18.10 or through backports to previous
releases. Moving forward all feature releases of LXD will only be
available through the snap.
"""

https://discuss.linuxcontainers.org/t/lxd-3-1-has-been-released/1787



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#768073: ITP: lxd -- The Linux Container Daemon

[Holger Schröder]

Hi folks,

I hope this is still alive. for a long time no response.


Greetings

Holger...

Bug#768073: ITP: lxd -- The Linux Container Daemon

[Harald Dunkel]

Hi folks,

is this ITP still alive?


Regards
Harri

Bug#768073: ITP: lxd - The Linux Container Daemon - LXC team take over ITP?

[Michael Hudson-Doyle]

On 24 September 2016 at 05:25, Anthony Fok  wrote:

> Hello all!
>
> (with added Cc to the Debian Go Team as well as
>
> On Fri, 23 Sep 2016 15:52:15 +0100 Jonathan Dowland 
> wrote:
> > Hi,
> >
> > I think that an ITP that has been inactive this long could be taken over
> by
> > another interested party without it being a hijack, all things
> considered.
> > (I think some QA script might move it to RFP soon anyway).
> >
> > Adnan, how's it going?
> >
> > There's a pkg-lxc team already. Since this package is/will be very
> inter-related to
> > LXC, perhaps it should be developed in that team? Team CCed. Are they
> interested?
> > Are you in pkg-lxc already?
> >
> > What's the state of the Ubuntu package? Could that make a good starting
> point? How
> > much hacking before that would be suitable for an experimental upload at
> least?
>
> I took a quick look at the package source obtained via:
>
> dget -u http://archive.ubuntu.com/ubuntu/pool/main/l/lxd/lxd_2.
> 2-0ubuntu1.dsc
>
> This Ubuntu package is being maintained as an official Ubuntu package
> by Canonical's Stéphane Graber, *the* LXC and LXD project leader
> himself!
> As such, the package has received much love, very professionally
> packaged and very mature.
>
> E: Unable to locate package golang-any-shared-dev
> E: Unable to locate package golang-gopkg-flosch-pongo2.v3-dev
> E: Unable to locate package golang-gopkg-inconshreveable-log15.v2-dev
> E: Unable to locate package golang-gopkg-lxc-go-lxc.v2-dev
> E: Unable to locate package golang-petname-dev
>
> golang-any-shared-dev can be ignored for now: it can simply be
> replaced by "golang-any" or similar in Debian.
> But wait, Ubuntu's Go actually has shared library support!?  What!?
> How?  Wow!  Amazing stuff!  Definitely news to me.
> See https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1508122
> and the patch by Michael Hudson-Doyle.  Okay, Cc'ing Michael too.  :-)
>

Heh, yep, finally! I'd like this stuff to land in Debian too but let's see
how it goes in Ubuntu for a while first. Probably something for after
stretch.

Cheers,
mwh

Bug#768073: [pkg-lxc-devel] Bug#768073: ITP: lxd - The Linux Container Daemon - LXC team take over ITP?

[Evgeni Golov]

Ohai,

On Fri, Sep 23, 2016 at 11:25:15AM -0600, Anthony Fok wrote:
> > I think that an ITP that has been inactive this long could be taken over by
> > another interested party without it being a hijack, all things considered.
> > (I think some QA script might move it to RFP soon anyway).
> >
> > Adnan, how's it going?
> >
> > There's a pkg-lxc team already. Since this package is/will be very 
> > inter-related to
> > LXC, perhaps it should be developed in that team? Team CCed. Are they 
> > interested?
> > Are you in pkg-lxc already?

Yes, Adnan is in pkg-lxc and technically the team is interested (given it falls 
into the same software stack) to have the whole stack available in Debian.
But I must admit I personally have no use for it and not enough Go knowledge to 
package it properly.

> > What's the state of the Ubuntu package? Could that make a good starting 
> > point? How
> > much hacking before that would be suitable for an experimental upload at 
> > least?

Yes, taking the Ubuntu package is a start is what we did with the other LXC 
components
and that worked out pretty well so far.

> I took a quick look at the package source obtained via:
> 
> dget -u 
> http://archive.ubuntu.com/ubuntu/pool/main/l/lxd/lxd_2.2-0ubuntu1.dsc
...
> So, I guess the first step would be to package
> golang-gopkg-flosch-pongo2.v3, golang-gopkg-inconshreveable-log15.v2,
> golang-gopkg-lxc-go-lxc.v2 and golang-petname, or simply grab these
> existing Ubuntu packages, make a few minor changes to debian/control
> and debian/changelog, file ITPs to the Debian BTS, and finally upload
> them to Debian.
> 
> I do not see too many hurdles after that, at least I hope not.  ;-)

IIRC that's similar to what Adnan told me the last time we talked about LXD.

> Also, should the Debian lxd be team-maintained by the pkg-lxc team or
> the pkg-go team?  What do you think?

Whatever works? :-)
Stack-wise it's more pkg-lxc, language-wise pkg-go...
I'd guess it will need coordination to both, LXC and other Go uploads at times 
too.

Greets
Evgeni

Bug#768073: ITP: lxd - The Linux Container Daemon - LXC team take over ITP?

[Anthony Fok]

Hello all!

(with added Cc to the Debian Go Team as well as

On Fri, 23 Sep 2016 15:52:15 +0100 Jonathan Dowland  wrote:
> Hi,
>
> I think that an ITP that has been inactive this long could be taken over by
> another interested party without it being a hijack, all things considered.
> (I think some QA script might move it to RFP soon anyway).
>
> Adnan, how's it going?
>
> There's a pkg-lxc team already. Since this package is/will be very 
> inter-related to
> LXC, perhaps it should be developed in that team? Team CCed. Are they 
> interested?
> Are you in pkg-lxc already?
>
> What's the state of the Ubuntu package? Could that make a good starting 
> point? How
> much hacking before that would be suitable for an experimental upload at 
> least?

I took a quick look at the package source obtained via:

dget -u 
http://archive.ubuntu.com/ubuntu/pool/main/l/lxd/lxd_2.2-0ubuntu1.dsc

This Ubuntu package is being maintained as an official Ubuntu package
by Canonical's Stéphane Graber, *the* LXC and LXD project leader
himself!
As such, the package has received much love, very professionally
packaged and very mature.

E: Unable to locate package golang-any-shared-dev
E: Unable to locate package golang-gopkg-flosch-pongo2.v3-dev
E: Unable to locate package golang-gopkg-inconshreveable-log15.v2-dev
E: Unable to locate package golang-gopkg-lxc-go-lxc.v2-dev
E: Unable to locate package golang-petname-dev

golang-any-shared-dev can be ignored for now: it can simply be
replaced by "golang-any" or similar in Debian.
But wait, Ubuntu's Go actually has shared library support!?  What!?
How?  Wow!  Amazing stuff!  Definitely news to me.
See https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1508122
and the patch by Michael Hudson-Doyle.  Okay, Cc'ing Michael too.  :-)

So, I guess the first step would be to package
golang-gopkg-flosch-pongo2.v3, golang-gopkg-inconshreveable-log15.v2,
golang-gopkg-lxc-go-lxc.v2 and golang-petname, or simply grab these
existing Ubuntu packages, make a few minor changes to debian/control
and debian/changelog, file ITPs to the Debian BTS, and finally upload
them to Debian.

I do not see too many hurdles after that, at least I hope not.  ;-)

And since the Ubuntu lxd package is the upstream here, I like to think
of the Debian lxd package as the downstream derivative, so we will
likely always wait for Stéphane to release -0ubuntu1, then apply any
necessary patches required for Debian, and upload that as -1.  What do
you think?  :-)

Also, should the Debian lxd be team-maintained by the pkg-lxc team or
the pkg-go team?  What do you think?

Cheers,

Anthony

Bug#768073: ITP: lxd - The Linux Container Daemon

[Thomas Goirand]

Hi Adnan,

It's been more than a month already since you've said that we should
"stay tuned". Well, I can't hold my breath anymore... :)

Is there any update on the release of this package? Is there a temporary
Git repository which we could use for this packaging?

FYI, I have packaged and I have just uploaded python-pylxd (it currently
is in the NEW queue), which is needed by OpenStack Manila (ie: file
share as a service).

The upstream sources of python-pylxd are very much like the other
OpenStack source code I've been packaging for OpenStack: it uses PBR,
has {test-,}requirements.txt, and has (build-)dependencies on many
OpenStack components. So it makes a lot of sense to have it packaged
under the PKG OpenStack.

The main use of LXD, from Canonical point of view, is also so it can be
leveraged by OpenStack compute (ie: nova-lxd), to provision LXC
containers instead of using KVM. So, from my point of view, it would
also make a lot of sense to maintain LXD within the PKG OpenStack group
as well. I of course welcome anyone in this packaging group on Alioth. I
would very much like to be co-maintaining this package as well (even if
I don't know Go packaging so much).

As soon as we have LXD in Debian, I will add a nova-lxd source package
to the nova source package, so that it can depend on LXD itself, and set
the relevant /etc/nova/nova-compute.conf options.

Your thoughts?

Cheers,

Thomas Goirand (zigo)

Bug#768073: ITP: lxd - The Linux Container Daemon

[Adnan Hodzic]

Hi Jonathan,

When Daniel orphaned this package I got ownership of this ITP. As during
DebConf I've expressed a wish to work on it.

Due to a lot of things happening in my life, I was too busy and didn't have
time to work on it yet.

But starting today, I'm starting on my work to get LXD into Debian. Stay
tuned and thanks for your understanding.


Regards,

Adnan

On Tue, Jan 26, 2016 at 4:50 PM, Jonathan Dowland  wrote:

> Hi,
>
> This ITP is now over a year old. Is this package still being worked on?
> Is there a public WIP repository or packages that people can see yet
> please?
>
>
> Thanks,
>
> --
> Jonathan Dowland
>

Bug#768073: ITP: lxd - The Linux Container Daemon

[Jonathan Dowland]

Hi,

This ITP is now over a year old. Is this package still being worked on?
Is there a public WIP repository or packages that people can see yet
please?


Thanks,

-- 
Jonathan Dowland

Bug#768073: ITP: lxd - The Linux Container Daemon

[Daniel Baumann]

Package: wnpp

* Package name : lxd
* URL : http://www.ubuntu.com/cloud/tools/lxd
* License : Apache 2
* Description :

(quoting from the website, not necessarily going to be the package
description..)

The Linux Container Daemon

The new hypervisor isn’t a hypervisor, and it’s much, much faster
LXD
What is LXD (“lex-dee”)?

Take all the speed and efficiency of docker, and turn it into a full
virtualisation experience. That’s the goal of Canonical’s new initiative
to create the next big hypervisor around Linux container technologies.

Imagine you could launch a new machine in under a second, and that you
could launch hundreds of them on a single server. Hundreds! Now, imagine
that you have hardware-guaranteed security to ensure that those machines
can’t pry or spy on one another. Imagine you can connect them separately
and securely to networks. And imagine that you can run that on a single
node or a million, live migrate machines between those nodes, and talk
to all of it through a clean, extensible REST API. That’s what LXD sets
out to deliver.

-- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org