Status update: I have updated the ci setup tool to create/update debian/gitlab-ci.yml: https://salsa.debian.org/go-team/ci/commits/master
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: https://salsa.debian.org/go-team/packages/golang-github- armon-go-socks5/-/jobs/8311 https://salsa.debian.org/go-team/packages/golang-github- opencontainers-go-digest/-/jobs/8323 https://salsa.debian.org/go-team/packages/golang-github- opencontainers-specs/-/jobs/8466 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. 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. Please let me know if you find any issues! On Tue, Feb 20, 2018 at 8:02 PM, Martín Ferrari <[email protected]> wrote: > On 20/02/18 12:20, Michael Stapelberg wrote: > > > I’m only aware of one package (jacobsa/crypto) which has a > > Debian-specific patch that requires the use of an architecture-specific > > build tag. My proposed solution for this is to either specify the > > architectures (as opposed to custom pointer size build tags) in the > > files (they change rarely enough), or at least add the amd64 > architecture. > > > > Are you aware of other packages which use the same technique? If so, it > > might be good to write up a little bit of documentation, and perhaps > > even make this a feature of dh-golang. > > the ones I have in mind would work for amd64 without the tags. Others > could be patched. The one that is not going to be easy without a lot of > medding is x/sys. > > > This particular example is moot since dh-golang 1.31’s > > install-testdata-by-default change :). > > Cool > > > I understand your concern. I suggest we try my suggested approach and > > re-evaluate at some point down the road (a quarter? a year?) whether > > keeping it up is feasible and worthwhile. We can always course-correct, > > there’s no lock-in here. > > Sounds good to me. > > -- > Martín Ferrari (Tincho) > -- Best regards, Michael
_______________________________________________ Pkg-go-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
