On Wed, Feb 7, 2018 at 12:01 PM, Clément Hermann <nod...@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-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers > -- Best regards, Michael