On Sun, 2021-10-31 at 12:54 +0100, Aloïs Micard wrote: > Hello there! > > On 10/31/21 5:22 AM, Mathias Gibbens wrote: > > I have done the packaging work for three Go libraries, and > > before > > moving to the RFS stage, would like to request/invite review from > > this > > team. Mostly I just want to be sure I'm following the team's > > preferred > > packaging workflow; of course, general packaging advice is also > > appreciated! > > > > Two packages were basically boilerplate that dh-make-golang > > largely > > handled: > > * > > https://salsa.debian.org/go-team/packages/golang-github-jkeiser-iter > > * > > https://salsa.debian.org/go-team/packages/golang-github-jaypipes-pcidb > > > > The first two packages looks in good shape! Both have been uploaded. > Only nitpick: I've done a minor change to d/copyright in golang- > github-jkeiser-iter > to match the LICENSE file.
Thanks, Aloïs! I see you also pushed tags, so those two packages should be done for the time being, unless they get a REJECT for some reason. > > > The third library was a bit more interesting, because its tests > > rely > > on udev actually having created the /dev/zero device, which isn't > > necessarily true in all build environments like containers or > > chroots. > > I came up with a kind of ugly check in d/rules to determine whether > > or > > not to run the tests at build time. It works for me performing > > builds > > in a lxc container, gbp using cowbuild, and debuild directly on a > > physical machine, but I'm open to any cleaner solutions. That > > package > > is at > > > > https://salsa.debian.org/go-team/packages/golang-github-farjump-go-libudev > > > > AFAIC the check in d/rules looks good. Build tested with sbuild as > well > on a LXC container and works. But maybe someone with more experience > should > step on just to confirm? > > > All three packages I think would be ready to upload, so I've set > > their changelogs to target unstable rather than UNRELEASED. > > Specific > > tags for the versions haven't yet been created, in case there is > > feedback to incorporate before uploading the package. > > > > Little note: I think it's best if you keep the changelog entry to > UNRELEASED > and let the uploader set it to unstable when doing the upload. This > way when > someone clone the repository they know exactly if the package has > been uploaded > yet or not. (Yes tags may give the same information but people lookup > d/changelog > more often). OK, I'll do that going forward. > > Of course, that's only a suggestion. > > > Thanks, > > Mathias > > > > Thanks for your work! Thanks for sponsoring! To keep the team up to date with my plans, I will be filing an ITP to reintroduce the golang-github-juju-testing package in a little while. It's at the center of what looks like a spaghetti graph of dependencies, so it's going to take some time to complete. While looking at that package's dependencies, I found some packages already in the archive that I plan to touch/update: * golang-github-juju-errors (orphaned, #889232) -- part of the golang-github-juju-testing spaghetti dependencies * golang-github-juju-loggo -- looks like it's been quite a while since the Debian package was updated * golang-github-juju-utils (RFA, #940381) -- part of the golang- github-juju-testing spaghetti dependencies * golang-github-juju-httpprof (RFA, #940378) -- looks like it just needs some janitorial packaging work * golang-gopkg-httprequest.v1 (RFA, #940445) -- looks like it's been quite a while since the Debian package was updated; has a new dependency on github.com/juju/qthttptest which will be filed as an ITP Mathias
signature.asc
Description: This is a digitally signed message part