Thanks for taking a look.

I see the role of the CI setup as complementary: I expect that people will
still build packages locally as they work on the packages. That path will
continue to cover the debian/* part of the package. The remainder (fit into
the archive) will be covered by the CI. In the worst case, the issue will
be caught on the buildds (provided one uses source-only uploads).

Regarding the amount of work required to make packages buildable directly
with the Go tool, have a look at the examples I listed at the bottom of the
document. I don’t expect to spend more than 15 minutes per package, and I
can volunteer to do the initial fixes. We need to be on the same page
regarding the longer-term strategy, though, otherwise packages will degrade

Does that address your concern?

On Mon, Feb 19, 2018 at 3:56 PM, Martín Ferrari <> wrote:

> Michael,
> On 19/02/18 09:25, Michael Stapelberg wrote:
> > I have spent the last two weeks on a different approach to our CI setup,
> > published the current version of the tools just now and added a document
> > to our website (not linked from the main page yet until I have some
> > feedback).
> This is a great initiative, thanks!
> Now, my main objection is to using the go tool directly and skipping the
> debian build system. I understand this is faster, but it also means that
> we could be missing problems in the debian files themselves, and that
> some packages will either fail or require a lot of work to avoid having
> any customisation in debian/rules.
> --
> Martín Ferrari (Tincho)

Best regards,
Pkg-go-maintainers mailing list

Reply via email to