Hi, On 2018-03-07 12:08, Hector Oron wrote: > Hello, > > 2018-03-07 12:01 GMT+01:00 Philipp Kern <pkern@debian.org>: > > Has it been tested? Well, lightly. Unfortunately I'm not really allowed to > > touch the buildds as root so it's kinda hard to replace the existing ones > > given that stuff is enforced by Puppet. So I did a few builds on zemlinsky. > > Should it be tested on one or two? Yes. In theory it should work. :) > > > >>> There were concerns about how DSA wanted this to be packaged (essentially > >>> not at all). > >> > >> > >> Sorry I missed those concerns, could you expand on them or link to > >> discussion? > > > > > > I mostly worked on this with Aurelien and the concern seems to have been > > that DSA would prefer user-based services with linger rather than packages. > > There are two ways to deploy it: > 1. Get the code in buildd via DSA puppet. > 2. Create Debian package, upload it, make a backport. Then it can be > deployed via backport. Can we move forward on that issue? Discussions on IRC suggested that using apt.buildd.debian.org, like it's done for the current packages is not the right choice. The suggested way to run things would be to just deploy things in ~buildd. As pybuildd uses systemd services, it means we need to enable lingering on buildds. Is it fine? The alternative as suggested by Hector is to use the package from backports. This means less flexibility if we need to update the code, as it will take at minimum 5 days following the policy. To do more tests I agree that we should deploy it on more buildds. For *this phase*, I believe enabling lingering and deploying it by hand is the best. Is it something acceptable? Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: PGP signature