<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 7, 2018 at 12:01 PM, Clément Hermann <span dir="ltr"><<a href="mailto:nodens@nodens.org" target="_blank">nodens@nodens.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/02/2018 11:39, Pete Heist wrote:<br>
><br>
> Ah, ok. IRTT has an API, but it's not published yet. I think a<br>
> binary-only package may be better at this point, and a separate source<br>
> package later when that’s ready? If you agree, could you suggest a<br>
> simple, current binary package hosted on github as a good example?<br>
<br>
</span>You can have a single upstream package and produce 2 binary packages -<br>
it's a bit more complicated though. Hence the example of Debian Code Search.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> Debian Code Search? Though its compat version is 8. I just liked how the<br>
> debian directory is hosted right in the github repo, which brings me to<br>
> another question...<br>
><br>
> Is it possible to maintain everything on github, or does it need to be<br>
> on alioth, and if so, what is a good workflow for when I want to pull in<br>
> changes from upstream for a new release?<br>
<br>
</span>Usually you would host the packaging on Alioth (soon <a href="http://salsa.debian.org" rel="noreferrer" target="_blank">salsa.debian.org</a>),<br>
and leave the upstream on github. Debian Code Search is a bit different<br>
since it's specific to Debian. That doesn't change the usefulness of the<br>
example for binary/api separation though.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regarding the workflow, the easiest is to tag your releases on github<br>
(you probably already do it anyway) and merge the upstream remote in the<br>
upstream branch on alioth/salsa every time you want to release (the tag<br>
isn't mandatory, it's just easier, and allows for a debian/watch file).<br>
<br>
[snip]<br>
<span class=""><br>
><br>
> Hrm, any idea why I'm seeing large differences in lintian output? I<br>
> didn’t see any warnings before I posted, but I do see new ones after the<br>
> .lintianrc changes, just they look completely different...<br>
><br>
> $ cat /etc/debian_version <br>
> 9.3<br>
> $ lintian --version<br>
> Lintian v2.5.50.4<br>
> $ cat .lintianrc <br>
> display-info = yes<br>
> display-experimental = yes<br>
> pedantic = yes<br>
> show-overrides = no<br>
> color = auto<br>
> $ lintian ~/src/<a href="http://github.com/peteheist/irtt/dpkg/irtt_0.9-1_amd64.changes" rel="noreferrer" target="_blank">github.com/peteheist/<wbr>irtt/dpkg/irtt_0.9-1_amd64.<wbr>changes</a><br>
</span>> <<a href="http://github.com/peteheist/irtt/dpkg/irtt_0.9-1_amd64.changes" rel="noreferrer" target="_blank">http://github.com/peteheist/<wbr>irtt/dpkg/irtt_0.9-1_amd64.<wbr>changes</a>><br>
<span class="">> P: irtt source: debian-watch-may-<wbr>check-gpg-signature<br>
> I: irtt: hardening-no-fortify-<wbr>functions usr/bin/irtt<br>
> I: irtt: spelling-error-in-<wbr>binary usr/bin/irtt writeN written<br>
> I: irtt: spelling-error-in-<wbr>binary usr/bin/irtt ot to<br>
> I: irtt: hardening-no-bindnow <wbr>usr/bin/irtt<br>
> I: irtt: hardening-no-pie usr/<wbr>bin/irtt<br>
> P: irtt: no-upstream-changelog<br>
><br>
> Also, some of the warnings (like compat-version) just come from output<br>
> from dh-make-golang, which I just installed with ‘apt-get install<br>
> dh-make-golang’. Do I need a newer version?<br>
<br>
</span>You're expected to run unstable (Sid) for packaging work. At least in a<br>
virtual machine.<br>
<br>
By the way, it's also a good practice to actually build the package in a<br>
chroot (using git-buildpackage pbuilder options for instance), to avoid<br>
build-depends issues.<br>
<br>
<br>
Cheers,<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
nodens<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Pkg-go-maintainers mailing list<br>
<a href="mailto:Pkg-go-maintainers@lists.alioth.debian.org">Pkg-go-maintainers@lists.<wbr>alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers" rel="noreferrer" target="_blank">http://lists.alioth.debian.<wbr>org/cgi-bin/mailman/listinfo/<wbr>pkg-go-maintainers</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>
</div></div>