[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging review request



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


Reply to: