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
Attachment:
signature.asc
Description: This is a digitally signed message part