[pkg-go] RFS: irtt/0.9-1 [ITP] (#888985)

[Michael Stapelberg]

On Wed, Feb 7, 2018 at 12:01 PM, Clément Hermann <nodens at nodens.org> wrote:

> On 07/02/2018 11:39, Pete Heist wrote:
> >
> > Ah, ok. IRTT has an API, but it's not published yet. I think a
> > binary-only package may be better at this point, and a separate source
> > package later when that’s ready? If you agree, could you suggest a
> > simple, current binary package hosted on github as a good example?
>
> You can have a single upstream package and produce 2 binary packages -
> it's a bit more complicated though. Hence the example of Debian Code
> Search.
>

Given the early stage of the API, I would agree that a binary-only package
is a good choice for now. Just modify debian/rules to delete the source
after installation and you should be good.


>
>
> > Debian Code Search? Though its compat version is 8. I just liked how the
> > debian directory is hosted right in the github repo, which brings me to
> > another question...
> >
> > Is it possible to maintain everything on github, or does it need to be
> > on alioth, and if so, what is a good workflow for when I want to pull in
> > changes from upstream for a new release?
>
> Usually you would host the packaging on Alioth (soon salsa.debian.org),
> and leave the upstream on github. Debian Code Search is a bit different
> since it's specific to Debian. That doesn't change the usefulness of the
> example for binary/api separation though.
>

Yeah, I agree: keeping debian/ in the upstream repo is usually not the best
solution: we really like to have our packages team-maintained, i.e. hosted
on our infrastructure alongside all of our other packages, with the same
workflows, etc.


>
> Regarding the workflow, the easiest is to tag your releases on github
> (you probably already do it anyway) and merge the upstream remote in the
> upstream branch on alioth/salsa every time you want to release (the tag
> isn't mandatory, it's just easier, and allows for a debian/watch file).
>
> [snip]
>
> >
> > Hrm, any idea why I'm seeing large differences in lintian output? I
> > didn’t see any warnings before I posted, but I do see new ones after the
> > .lintianrc changes, just they look completely different...
> >
> > $ cat /etc/debian_version
> > 9.3
> > $ lintian --version
> > Lintian v2.5.50.4
> > $ cat .lintianrc
> > display-info = yes
> > display-experimental = yes
> > pedantic = yes
> > show-overrides = no
> > color = auto
> > $ lintian ~/src/github.com/peteheist/irtt/dpkg/irtt_0.9-1_amd64.changes
> > <http://github.com/peteheist/irtt/dpkg/irtt_0.9-1_amd64.changes>
> > P: irtt source: debian-watch-may-check-gpg-signature
> > I: irtt: hardening-no-fortify-functions usr/bin/irtt
> > I: irtt: spelling-error-in-binary usr/bin/irtt writeN written
> > I: irtt: spelling-error-in-binary usr/bin/irtt ot to
> > I: irtt: hardening-no-bindnow usr/bin/irtt
> > I: irtt: hardening-no-pie usr/bin/irtt
> > P: irtt: no-upstream-changelog
> >
> > Also, some of the warnings (like compat-version) just come from output
> > from dh-make-golang, which I just installed with ‘apt-get install
> > dh-make-golang’. Do I need a newer version?
>
> You're expected to run unstable (Sid) for packaging work. At least in a
> virtual machine.
>
> By the way, it's also a good practice to actually build the package in a
> chroot (using git-buildpackage pbuilder options for instance), to avoid
> build-depends issues.
>
>
> Cheers,
>
> --
> nodens
>
> _______________________________________________
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20180207/3dd1e950/attachment.html>