Bug#1002564: lxc: packaging adjustments for LXD
I've verified that the changes in lxc's packaging as of 1:4.0.11- 1~exp2 are good, at least from my vantage point of working on LXD. I've built and put LXD through its paces on a fresh install with the experimental version of lxc, and everything is working as expected. Plus, it now only depends on liblxc1 and liblxc-common! :) Thanks for your assistance with this! Mathias signature.asc Description: This is a digitally signed message part
Bug#1002564: [pkg-lxc-devel] Bug#1002564: lxc: packaging adjustments for LXD
Hi Mathias,
Mathias Gibbens wrote on 29/01/2022 at 03:41:40+0100:
> On Fri, 2022-01-28 at 01:33 +0100, Pierre-Elliott Bécue wrote:
>> I've made some changes I've decided to upload on salsa and on
>> experimental.
>>
>> If you're able to test these changes on some clean environment, I'd
>> be
>> happy if you could do it as I like the time to redo a clean testing
>> environment for lxc right now.
>>
>> If you can't, I'll try to do it this weekend or during the next week.
>
> Thanks! I took a quick look this evening and noticed one thing -- the
> directory `usr/lib/*/lxc/rootfs` is still listed in the d/lxc.install
> file. Can that also get moved over into the liblxc-common package? LXD
> expects to be able to use that directory similarly to lxc when starting
> up containers.
Ah, sorry. It slipped out from my sight.
> As it looks like liblxc-common is including the
> /usr/sbin/init.lxc{,.static} binaries it can't be an Architecture: all
> package, so having a directory with an architecture-dependent path
> hopefully won't be an issue. (Side note, in d/control, would it make
> sense to keep liblxc-common as Architecture: linux-any to match all the
> other binary packages that are built?)
Indeed! You're right. I've changed to linux-any.
> I'll do a build and test of LXD in a fresh environment this weekend
> and report back on any other issues I find.
Thanks for your feedback and for spotting these issues. :)
--
PEB
signature.asc
Description: PGP signature
Bug#1002564: [pkg-lxc-devel] Bug#1002564: lxc: packaging adjustments for LXD
On Fri, 2022-01-28 at 01:33 +0100, Pierre-Elliott Bécue wrote:
> I've made some changes I've decided to upload on salsa and on
> experimental.
>
> If you're able to test these changes on some clean environment, I'd
> be
> happy if you could do it as I like the time to redo a clean testing
> environment for lxc right now.
>
> If you can't, I'll try to do it this weekend or during the next week.
Thanks! I took a quick look this evening and noticed one thing -- the
directory `usr/lib/*/lxc/rootfs` is still listed in the d/lxc.install
file. Can that also get moved over into the liblxc-common package? LXD
expects to be able to use that directory similarly to lxc when starting
up containers.
As it looks like liblxc-common is including the
/usr/sbin/init.lxc{,.static} binaries it can't be an Architecture: all
package, so having a directory with an architecture-dependent path
hopefully won't be an issue. (Side note, in d/control, would it make
sense to keep liblxc-common as Architecture: linux-any to match all the
other binary packages that are built?)
I'll do a build and test of LXD in a fresh environment this weekend
and report back on any other issues I find.
Mathias
signature.asc
Description: This is a digitally signed message part
Bug#1002564: [pkg-lxc-devel] Bug#1002564: lxc: packaging adjustments for LXD
Le dimanche 26 décembre 2021 à 16:03:41+, Mathias Gibbens a écrit : > On Sun, 26 Dec 2021 12:33:43 -0300 Antonio Terceiro > wrote: > > On Sat, Dec 25, 2021 at 02:25:06PM +, Evgeni Golov wrote: > > > On December 25, 2021 12:35:45 PM UTC, Antonio Terceiro > wrote: > > > >They probably would need to be provided by a (NEW) lxc-common > package. > > > >If we ever need to transition to liblxc2, we don't want both > liblxc* > > > >packages providing those files. > > > > > > On Ubuntu, this package us called liblxc-common, which we probably > > > should also use, to make life of other consumers easier? > > > > Sure! I didn't check there first. > > I think a liblxc-common package should work just fine. I haven't > found any other files in the lxc package that LXD is expecting to have > around, but if I do I'll update this bug. > > I'm happy to help test any changes to the packaging when they're > ready. > > Thanks! I've made some changes I've decided to upload on salsa and on experimental. If you're able to test these changes on some clean environment, I'd be happy if you could do it as I like the time to redo a clean testing environment for lxc right now. If you can't, I'll try to do it this weekend or during the next week. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1002564: [pkg-lxc-devel] Bug#1002564: lxc: packaging adjustments for LXD
On Sun, 26 Dec 2021 12:33:43 -0300 Antonio Terceiro wrote: > On Sat, Dec 25, 2021 at 02:25:06PM +, Evgeni Golov wrote: > > On December 25, 2021 12:35:45 PM UTC, Antonio Terceiro wrote: > > >They probably would need to be provided by a (NEW) lxc-common package. > > >If we ever need to transition to liblxc2, we don't want both liblxc* > > >packages providing those files. > > > > On Ubuntu, this package us called liblxc-common, which we probably > > should also use, to make life of other consumers easier? > > Sure! I didn't check there first. I think a liblxc-common package should work just fine. I haven't found any other files in the lxc package that LXD is expecting to have around, but if I do I'll update this bug. I'm happy to help test any changes to the packaging when they're ready. Thanks! Mathias signature.asc Description: This is a digitally signed message part
Bug#1002564: [pkg-lxc-devel] Bug#1002564: lxc: packaging adjustments for LXD
On Sat, Dec 25, 2021 at 02:25:06PM +, Evgeni Golov wrote: > > > On December 25, 2021 12:35:45 PM UTC, Antonio Terceiro > wrote: > >On Fri, Dec 24, 2021 at 06:04:04AM +, Mathias Gibbens wrote: > >> Source: lxc > >> Version: 1:4.0.10-1 > >> Severity: normal > >> > >> Work on packaging LXD for Debian (ITP #768073) is getting pretty > >> close to completion. I've recently started testing the LXD package that > >> I am able to build locally, making sure everything is working properly > >> before it's uploaded to NEW once the few remaining dependencies make it > >> through NEW themselves. > >> > >> LXD depends on the liblxc1 package, but not on the lxc package > >> itself. However, there are a few files currently shipped in the lxc > >> package that LXD needs to properly start. Specifically, the apparmor > >> profiles (all of /etc/apparmor.d/, except /etc/apparmor.d/usr.bin.lxc- > >> start) and the /usr/lib/-linux-gnu/lxc/rootfs/ directory. > >> > >> I'm hoping we can figure out a nice way to make these dependencies of > >> LXD available without having to pull in lxc itself (plus its own > >> dependencies). The easiest way might be to just move them to liblxc1, > >> which both lxc and LXD packages will depend on. Or, there might be some > >> other solution that could work. > > > >They probably would need to be provided by a (NEW) lxc-common package. > >If we ever need to transition to liblxc2, we don't want both liblxc* > >packages providing those files. > > On Ubuntu, this package us called liblxc-common, which we probably > should also use, to make life of other consumers easier? Sure! I didn't check there first. signature.asc Description: PGP signature
Bug#1002564: [pkg-lxc-devel] Bug#1002564: lxc: packaging adjustments for LXD
On December 25, 2021 12:35:45 PM UTC, Antonio Terceiro wrote: >On Fri, Dec 24, 2021 at 06:04:04AM +, Mathias Gibbens wrote: >> Source: lxc >> Version: 1:4.0.10-1 >> Severity: normal >> >> Work on packaging LXD for Debian (ITP #768073) is getting pretty >> close to completion. I've recently started testing the LXD package that >> I am able to build locally, making sure everything is working properly >> before it's uploaded to NEW once the few remaining dependencies make it >> through NEW themselves. >> >> LXD depends on the liblxc1 package, but not on the lxc package >> itself. However, there are a few files currently shipped in the lxc >> package that LXD needs to properly start. Specifically, the apparmor >> profiles (all of /etc/apparmor.d/, except /etc/apparmor.d/usr.bin.lxc- >> start) and the /usr/lib/-linux-gnu/lxc/rootfs/ directory. >> >> I'm hoping we can figure out a nice way to make these dependencies of >> LXD available without having to pull in lxc itself (plus its own >> dependencies). The easiest way might be to just move them to liblxc1, >> which both lxc and LXD packages will depend on. Or, there might be some >> other solution that could work. > >They probably would need to be provided by a (NEW) lxc-common package. >If we ever need to transition to liblxc2, we don't want both liblxc* >packages providing those files. On Ubuntu, this package us called liblxc-common, which we probably should also use, to make life of other consumers easier?
Bug#1002564: lxc: packaging adjustments for LXD
On Fri, Dec 24, 2021 at 06:04:04AM +, Mathias Gibbens wrote: > Source: lxc > Version: 1:4.0.10-1 > Severity: normal > > Work on packaging LXD for Debian (ITP #768073) is getting pretty > close to completion. I've recently started testing the LXD package that > I am able to build locally, making sure everything is working properly > before it's uploaded to NEW once the few remaining dependencies make it > through NEW themselves. > > LXD depends on the liblxc1 package, but not on the lxc package > itself. However, there are a few files currently shipped in the lxc > package that LXD needs to properly start. Specifically, the apparmor > profiles (all of /etc/apparmor.d/, except /etc/apparmor.d/usr.bin.lxc- > start) and the /usr/lib/-linux-gnu/lxc/rootfs/ directory. > > I'm hoping we can figure out a nice way to make these dependencies of > LXD available without having to pull in lxc itself (plus its own > dependencies). The easiest way might be to just move them to liblxc1, > which both lxc and LXD packages will depend on. Or, there might be some > other solution that could work. They probably would need to be provided by a (NEW) lxc-common package. If we ever need to transition to liblxc2, we don't want both liblxc* packages providing those files. signature.asc Description: PGP signature
Bug#1002564: lxc: packaging adjustments for LXD
Source: lxc Version: 1:4.0.10-1 Severity: normal Work on packaging LXD for Debian (ITP #768073) is getting pretty close to completion. I've recently started testing the LXD package that I am able to build locally, making sure everything is working properly before it's uploaded to NEW once the few remaining dependencies make it through NEW themselves. LXD depends on the liblxc1 package, but not on the lxc package itself. However, there are a few files currently shipped in the lxc package that LXD needs to properly start. Specifically, the apparmor profiles (all of /etc/apparmor.d/, except /etc/apparmor.d/usr.bin.lxc- start) and the /usr/lib/-linux-gnu/lxc/rootfs/ directory. I'm hoping we can figure out a nice way to make these dependencies of LXD available without having to pull in lxc itself (plus its own dependencies). The easiest way might be to just move them to liblxc1, which both lxc and LXD packages will depend on. Or, there might be some other solution that could work. Realistically it's still going to be at least a couple of weeks before LXD is ready for upload to NEW, so we've got some time to figure this out. Thanks, Mathias signature.asc Description: This is a digitally signed message part
