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

2022-02-06 Thread 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: [pkg-lxc-devel] Bug#768073: ITP: lxd - The Linux Container Daemon

2021-01-19 Thread 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: [pkg-lxc-devel] Bug#768073: ITP: lxd - The Linux Container Daemon - LXC team take over ITP?

2016-09-25 Thread 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