Re: Announce: docker-buildpackage

[Hugo Shepherd]

On Thu, 3 May 2018 at 09:10, Johannes Schauer  wrote:

> Quoting Chow Loong Jin (2018-05-03 06:27:01)
> > On Wed, May 02, 2018 at 11:23:56AM +0200, Thomas Goirand wrote:
> > > [...]
> > > Frankly, I don't see the point in writing this kind of software. Sbuild
> > > works super well with the overlay backend, and already has throw-able
> > > chroots in tmpfs. Adding docker into this doesn't add any new feature,
> > > and in some way, is less flexible than the already existing sbuild.
> >
> > Something that comes to mind is network isolation, which sbuild still
> > doesn't seem to have proper support[1] for:
> >
> > [1]
> https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage
>
> sbuild cannot have or not have support for network isolation. Network
> isolation
> is a feature of the backend and not of sbuild. In this case, the default
> sbuild
> backend (schroot) does not have support for it yet. The bug is even linked
> in
> the wiki section you quote.
>
> If you want network isolation today, just pick one of the other backends
> that
> sbuild supports via autopkgtest (the lxc backend probably supports network
> isolation). If you want network isolation with the schroot backend, then
> you
> have to improve schroot and not sbuild.
>
> I also think that, if you want a docker builder today, it would be *much*
> easier to just add a docker backend to an existing package building
> software
> like pbuilder or sbuild and thus avoid re-implementing all the "package
> building" logic and focus on the docker specific things instead.
>
> Thanks!
>
> cheers, josch
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Announce: docker-buildpackage

[Thomas Goirand]

On 05/01/2018 03:23 PM, Enrico Weigelt, metux IT consult wrote:
> Hi folks,
> 
> 
> I've written a tool for isolated deb builds in docker containers.
> It's a little bit like pbuilder, but using docker for isolation.
> 
> https://github.com/metux/docker-buildpackage
> 
> Everything written in shellscript, simple config as sh includes.
> Not debianized yet, as it might require some local customizations.
> (planned for future releases)
> 
> I'm also hacking on another tool which automatically clones repos
> and calls dck-buildpackage for building whole pipelines - but that's
> still experimental and hackish:
> 
> https://github.com/metux/deb-pkg
> 
> 
> --mtx

Hi,

Frankly, I don't see the point in writing this kind of software. Sbuild
works super well with the overlay backend, and already has throw-able
chroots in tmpfs. Adding docker into this doesn't add any new feature,
and in some way, is less flexible than the already existing sbuild.

Instead, I very much would prefer a patch to puiparts so that it could
use sbuild's schroot system instead of tarballs.

Cheers,

Thomas Goirand (zigo)

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Announce: docker-buildpackage

[Johannes Schauer]

Quoting Chow Loong Jin (2018-05-03 06:27:01)
> On Wed, May 02, 2018 at 11:23:56AM +0200, Thomas Goirand wrote:
> > [...]
> > Frankly, I don't see the point in writing this kind of software. Sbuild
> > works super well with the overlay backend, and already has throw-able
> > chroots in tmpfs. Adding docker into this doesn't add any new feature,
> > and in some way, is less flexible than the already existing sbuild.
> 
> Something that comes to mind is network isolation, which sbuild still
> doesn't seem to have proper support[1] for:
> 
> [1] 
> https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage

sbuild cannot have or not have support for network isolation. Network isolation
is a feature of the backend and not of sbuild. In this case, the default sbuild
backend (schroot) does not have support for it yet. The bug is even linked in
the wiki section you quote.

If you want network isolation today, just pick one of the other backends that
sbuild supports via autopkgtest (the lxc backend probably supports network
isolation). If you want network isolation with the schroot backend, then you
have to improve schroot and not sbuild.

I also think that, if you want a docker builder today, it would be *much*
easier to just add a docker backend to an existing package building software
like pbuilder or sbuild and thus avoid re-implementing all the "package
building" logic and focus on the docker specific things instead.

Thanks!

cheers, josch


signature.asc
Description: signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Announce: docker-buildpackage

[Martin Pitt]

Chow Loong Jin [2018-05-03 12:27 +0800]:
> On Wed, May 02, 2018 at 11:23:56AM +0200, Thomas Goirand wrote:
> > [...]
> > Frankly, I don't see the point in writing this kind of software. Sbuild
> > works super well with the overlay backend, and already has throw-able
> > chroots in tmpfs. Adding docker into this doesn't add any new feature,
> > and in some way, is less flexible than the already existing sbuild.
> 
> Something that comes to mind is network isolation, which sbuild still
> doesn't seem to have proper support[1] for:
> 
> [1] 
> https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage

Not just network, but also process isolation and reducing privileges. schroot
would be way too "leaky" for a production CI system like ci.debian.net or
autopkgtest.ubuntu.com. The existing backend that compare much better to that
are -lxc and -lxd, and IMHO they are superior to docker. lxc and lxd are "full
OS" containers while docker is optimized for application containers and thus
needs some special treatment (like --privileged, which makes the whole thing
rather unsafe and often causes crashes if you try to start udev in the docker
container) to allow really booting a full OS. Usability wise, they are just as
simple as docker too, as linuxcontainers.org has a lot of pre-built OS images
for all kinds of OSes.

So I agree that there is very little point about adding a docker backend other
than "it's possible" (albeit inferior). As long as someone wants to maintain
it, there is little harm in including it.

Martin


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Announce: docker-buildpackage

[Chow Loong Jin]

On Wed, May 02, 2018 at 11:23:56AM +0200, Thomas Goirand wrote:
> [...]
> Frankly, I don't see the point in writing this kind of software. Sbuild
> works super well with the overlay backend, and already has throw-able
> chroots in tmpfs. Adding docker into this doesn't add any new feature,
> and in some way, is less flexible than the already existing sbuild.

Something that comes to mind is network isolation, which sbuild still
doesn't seem to have proper support[1] for:

[1] 
https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel