<div dir="ltr">Status update:<div><br></div><div>I have updated the ci setup tool to create/update debian/gitlab-ci.yml: <a href="https://salsa.debian.org/go-team/ci/commits/master" target="_blank">https://<wbr>salsa.debian.org/go-team/ci/co<wbr>mmits/master</a></div><div><br></div><div>I ran this yesterday and had it do a CI run for all of our repositories. There were 3 failures, all of which because the repository in question has a debian/changelog entry whose version git-buildpackage cannot find as a tag:</div><div><div><br></div><div><a href="https://salsa.debian.org/go-team/packages/golang-github-armon-go-socks5/-/jobs/8311" target="_blank">https://salsa.debian.org/go-<wbr>team/packages/golang-github-<wbr>armon-go-socks5/-/jobs/8311</a></div><div><a href="https://salsa.debian.org/go-team/packages/golang-github-opencontainers-go-digest/-/jobs/8323" target="_blank">https://salsa.debian.org/go-<wbr>team/packages/golang-github-<wbr>opencontainers-go-digest/-/<wbr>jobs/8323</a></div><div><a href="https://salsa.debian.org/go-team/packages/golang-github-opencontainers-specs/-/jobs/8466" target="_blank">https://salsa.debian.org/go-<wbr>team/packages/golang-github-<wbr>opencontainers-specs/-/jobs/<wbr>8466</a></div></div><div><br></div><div>Aside from that, things look good, so I’m running the ci tool periodically (every hour) to configure newly created repositories appropriately. Longer-term, I’ll need to think about how to best integrate it with repository creation via dh-make-golang: putting the code into dh-make-golang itself might not be the best idea. We’ve seen people use old versions in the past, so there is a chance we’ll get unexpected differences in how our repositories are set up.</div><div><br></div><div>Regarding the CI itself, after pushing your changes to the master (or debian/*) branch, the Debian archive will be built, your changes will be applied, and the archive will be built again. Any new issues will be reported. This takes approximately a minute or two, so I would recommend to wait for the CI results before uploading to Debian.</div><div><br></div><div>Please let me know if you find any issues!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 20, 2018 at 8:02 PM, Martín Ferrari <span dir="ltr"><<a href="mailto:tincho@tincho.org" target="_blank">tincho@tincho.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 20/02/18 12:20, Michael Stapelberg wrote:<br>
<br>
> I’m only aware of one package (jacobsa/crypto) which has a<br>
> Debian-specific patch that requires the use of an architecture-specific<br>
> build tag. My proposed solution for this is to either specify the<br>
> architectures (as opposed to custom pointer size build tags) in the<br>
> files (they change rarely enough), or at least add the amd64 architecture.<br>
><br>
> Are you aware of other packages which use the same technique? If so, it<br>
> might be good to write up a little bit of documentation, and perhaps<br>
> even make this a feature of dh-golang.<br>
<br>
</span>the ones I have in mind would work for amd64 without the tags. Others<br>
could be patched. The one that is not going to be easy without a lot of<br>
medding is x/sys.<br>
<span class=""><br>
> This particular example is moot since dh-golang 1.31’s<br>
> install-testdata-by-default change :).<br>
<br>
</span>Cool<br>
<span class=""><br>
> I understand your concern. I suggest we try my suggested approach and<br>
> re-evaluate at some point down the road (a quarter? a year?) whether<br>
> keeping it up is feasible and worthwhile. We can always course-correct,<br>
> there’s no lock-in here.<br>
<br>
</span>Sounds good to me.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Martín Ferrari (Tincho)<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>
</div>