Bug#888985: ITP: irtt -- Isochronous Round-Trip Tester

[Pete Heist]

Package: wnpp
Severity: wishlist
Owner: Pete Heist <p...@eventide.io>
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

* Package name: irtt
  Version : 0.9+git20180131.0.7d52098-1
  Upstream Author : Pete Heist
* URL : https://github.com/peteheist/irtt
* License : GPL-3.0
  Programming Lang: Go
  Description : Isochronous Round-Trip Tester

 IRTT (Isochronous Round-Trip Tester) IRTT measures round-trip time and
 other metrics using UDP packets sent on a fixed period, and produces
 both user and machine parseable output. See https://github.com/peteheist/irtt
 for more information.

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

[Pete Heist]

> On Feb 7, 2018, at 10:03 AM, Michael Stapelberg  wrote:
> 
> Thanks for contributing this package.
> 
> The resulting binary package irtt_0.9-1_amd64.deb contains both a binary and 
> Go source code. This is a bit unusual: in Debian, we only package Go source 
> code to build other Go programs (not for developers). Hence, we usually 
> provide either a binary package with programs or an arch:all package with Go 
> source. It’s fine to have a source package which provides both, but please 
> separate the source from the binaries. Have a look at 
> https://anonscm.debian.org/cgit/collab-maint/codesearch.git/ 
>  for an example 
> of this pattern.
> 
> Further, please address the following lintian warnings:
> 
> P: irtt source: package-uses-old-debhelper-compat-version 10
> P: irtt source: insecure-copyright-format-uri 
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ 
> 
> I: irtt source: out-of-date-standards-version 3.9.8 (released 2016-04-06) 
> (current is 4.1.3)
> I: irtt source: testsuite-autopkgtest-missing
> W: irtt: priority-extra-is-replaced-by-priority-optional

I’m on Debian sid and closer now, with a binary only package (using 
dh_auto_install -- --no-source). There’s still some lintian confusion. When I 
run it, I get:

$ cat /etc/debian_version 
buster/sid
$ lintian --version
Lintian v2.5.74
$ lintian irtt_0.9+git20180209.9cda776-1_amd64.changes
P: irtt source: debian-watch-does-not-check-gpg-signature
P: irtt: no-upstream-changelog

From the original warnings you sent I know I’ve fixed all except "I: irtt 
source: testsuite-autopkgtest-missing”, but a) I’m not seeing that warning and 
b) I’m seeing two others. So my questions are:

1) What are your expectations for 'testsuite-autopkgtest-missing', and why am I 
not seeing it? There are no unit tests to run.

2) Do you care about 'debian-watch-does-not-check-gpg-signature' and 
'no-upstream-changelog’? I do not sign the upstream, and the changes are in 
README.md, in case those should be split out...

Thanks!
Pete

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

[Pete Heist]

> On Feb 7, 2018, at 10:36 PM, Michael Stapelberg  wrote:
> 
> Ok, I’m getting there, bear with me. :) In my case, would I not want to 
> produce both a binary package and eventually a source package?
> 
> Be careful not to confuse the Debian concept of source packages (i.e. .dsc 
> files) and binary packages (i.e. .deb files) with a Debian binary package 
> containing binary files (e.g. a .deb with files in /usr/bin) and a Debian 
> binary package containing Go source code (e.g. a .deb with files in 
> /usr/share/gocode).
> 
> You always operate on 1 Debian source package (in your case, named irtt) 
> generating at least 1 Debian binary package (in your case, also named irtt). 
> We discussed generating 2 Debian binary packages (irtt and 
> golang-github-peteheist-irtt-dev).

Ok, that’s clear to me now. The solution of one binary package for now sounds 
best. I can have the same source package generate the second binary (with 
source) package later. I just need to get up to Debian sid and take care of any 
other lintian warnings also. Thanks!

Pete

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

[Pete Heist]

> On Feb 9, 2018, at 8:15 AM, Michael Stapelberg <stapelb...@debian.org> wrote:
> 
> On Fri, Feb 9, 2018 at 2:09 AM, Pete Heist <p...@eventide.io 
> <mailto:p...@eventide.io>> wrote:
> 
> From the original warnings you sent I know I’ve fixed all except "I: irtt 
> source: testsuite-autopkgtest-missing”, but a) I’m not seeing that warning 
> and b) I’m seeing two others. So my questions are:
> 
> 1) What are your expectations for 'testsuite-autopkgtest-missing', and why am 
> I not seeing it? There are no unit tests to run.
> 
> Did you apply the ~/.lintianrc I provided? Not doing so would explain the 
> difference. autopkgtest is helpful even if it only compiles the package in 
> question. Why are there no unit tests for your code? :)

Yes I did, I should have included that...

$ lintian --version
Lintian v2.5.74
$ ls -al ~/.lintianrc 
-rw-r--r-- 1 pete pete 94 Feb  7 10:25 /home/pete/.lintianrc
$ cat ~/.lintianrc 
display-info = yes
display-experimental = yes
pedantic = yes
show-overrides = no
color = auto
$

What probably explains your seeing testsuite-autopkgtest-missing and my not is 
that I was previously using dh-make-golang from Debian stable. The current sid 
version of dh-make-golang has added a "Testsuite: autopkgtest-pkg-go” line to 
debian/control, which likely satisfies lintian.

BTW I manually bumped compat-version from 10 to 11 and standards-version from 
4.1.1 to 4.1.3 as recent changes to dh-make-golang which do this aren’t in sid 
yet.

As for unit tests, in short, I haven’t gotten there yet, though there’s a bit 
more to it than that. If you’d like, I can add a few basic ones to satisfy, 
otherwise they’ll go in after one more design issue is sorted out… :)

> 2) Do you care about 'debian-watch-does-not-check-gpg-signature' and 
> 'no-upstream-changelog’? I do not sign the upstream, and the changes are in 
> README.md, in case those should be split out...
> 
> They’re not important for the time being. Of course, if you could start 
> signing upstream and provide a separate changelog file, that would be great.
> 
> Thanks!

Ok, I’ll take a look at these if there’s time.

Thanks, almost there… :)

Bug#888985: IRTT source pushed

[Pete Heist]

Hi, my apologies for my inexperience building debian packages. I pushed the 
IRTT source following the instructions for dh-make-golang. The flent package in 
pkg-netmeasure is looking forward to using this as a dependency. Is there 
anything else needed from me?

Thanks!
Pete

Bug#888985: IRTT source pushed

[Pete Heist]

> On Feb 6, 2018, at 7:41 PM, nodens  wrote:
> 
> You should probably send an explicit request for sponsor (RFS), on the
> pkg-go-maintainer list, while leaving the bug in CC and with a specific
> subject like "RFS: IRTT (#888985)" to allow your request to stand out a
> bit in the flow of notification (or ask again on IRC but staying a bit
> longer so people can reply later if they don't see your message
> immediately).

Many thanks, I’ve now done so… :)

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

[Pete Heist]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "irtt"

 Package name: irtt
 Version : 0.9-1
 Upstream Author : Pete Heist <p...@eventide.io <mailto:p...@eventide.io>>
 URL : https://github.com/peteheist/irtt
 License : GPL-3
 Section : devel

It builds those binary packages:

  irtt  - Isochronous Round-Trip Tester

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/irtt

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/i/irtt/irtt_0.9-1.dsc

More information about irtt can be obtained from 
https://github.com/peteheist/irtt.

The flent package (https://packages.debian.org/source/sid/flent) from 
pkg-netmeasure will use irtt as a dependency.

Changes since the last upload: none

Regards,
Pete Heist

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

[Pete Heist]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "irtt"

 Package name: irtt
 Version : 0.9-1
 Upstream Author : Pete Heist <p...@eventide.io <mailto:p...@eventide.io>>
 URL : https://github.com/peteheist/irtt 
<https://github.com/peteheist/irtt>
 License : GPL-3
 Section : devel

It builds those binary packages:

  irtt  - Isochronous Round-Trip Tester

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/irtt 
<https://mentors.debian.net/package/irtt>

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/i/irtt/irtt_0.9-1.dsc 
<https://mentors.debian.net/debian/pool/main/i/irtt/irtt_0.9-1.dsc>

More information about irtt can be obtained from 
https://github.com/peteheist/irtt <https://github.com/peteheist/irtt>.

The flent package (https://packages.debian.org/source/sid/flent 
<https://packages.debian.org/source/sid/flent>) from pkg-netmeasure will use 
irtt as a dependency.

Changes since the last upload: none

Regards,
Pete Heist

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

[Pete Heist]

> On Feb 12, 2018, at 10:22 PM, Michael Stapelberg  
> wrote:
> 
> Would you like me to sponsor the upload of irtt now?

Yes, if you would. Thanks!

Pete

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

[Pete Heist]

> On Feb 11, 2018, at 12:37 AM, Michael Stapelberg <stapelb...@debian.org> 
> wrote:
> 
> On Sat, Feb 10, 2018 at 6:08 PM, Pete Heist <p...@eventide.io 
> <mailto:p...@eventide.io>> wrote:
> 
> - I tried getting signatures working but punted because GitHub creates a 
> .tar.gz, which I signed with a .tar.gz.asc, but the build process expects a 
> .tar.xz.asc in the upstream, so lintian then warns with 
> 'orig-tarball-missing-upstream-signature'. Is there any pkg-go example of 
> signatures working with a GitHub hosted repo? Otherwise I’ll eventually 
> figure it out.
> 
> The process currently is a bit clunky. dh-make-golang hardcodes using xz (via 
> tar J), so either you change that in dh-make-golang’s source, or you manually 
> create the packaging git repository:
> 
> # save GitHub .tar.gz as irtt_0.9.0.orig.tar.gz
> % mkdir irtt
> % cd irtt
> % git init
> % gbp import-orig ../irtt_0.9.0.orig.tar.gz
> % cp -r /tmp/dh-make-golang/irtt/debian .
> % git commit -a -m "Initial packaging”
>  
> 
> Let me know if anything else. Thanks!
> 
> It would be good to avoid copying the systemd .service file into debian/. I 
> think you can instead install it with a debian/rules override. See e.g. 
> https://sources.debian.org/src/forked-daapd/25.0-2/debian/rules/?hl=22#L22 
> <https://sources.debian.org/src/forked-daapd/25.0-2/debian/rules/?hl=22#L22>
> 
> Let me know how you’d like to proceed regarding the signatures. It’s not a 
> requirement to sign the releases for now, but note that after the initial 
> upload, we don’t have the luxury of starting with a fresh repository anymore.

Ok, I took the advice for the .service file (thanks, that’s smoother), and 
re-initialized the repo for the last time. :)

I passed on signing for now. I modified dh-make-golang to make a .tar.gz 
(thought I might even submit a pull request with a new command line option), 
but the .tar.gz that’s created is not the same as the one GitHub automatically 
creates (different internal directory names for starters), so for each build it 
looks like I’d have to:
- Run gbp once to generate the .tar.gz
- Sign it to get the .tar.gz.asc
- Run gbp again with the .tar.gz.asc in place to see that lintian doesn’t 
complain
- Manually upload the .tar.gz and .tar.gz.asc to GitHub
In the interest of keeping my release process as simple as possible, I’ll 
smooth this out later when I have more time!

One more thing: I switched to semantic versioning when I started CHANGES.md, so 
on ftp.upload.debian.org what was irtt_0.9-1* before is now irtt_0.9.0-1*, in 
case there are some dangling files there that should be cleaned up.

Thanks again!

Pete

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

[Pete Heist]

> On Feb 12, 2018, at 11:05 PM, Pete Heist <p...@eventide.io> wrote:
> 
>> On Feb 12, 2018, at 10:22 PM, Michael Stapelberg <stapelb...@debian.org 
>> <mailto:stapelb...@debian.org>> wrote:
>> 
>> Would you like me to sponsor the upload of irtt now?
> 
> Yes, if you would. Thanks!

Glad to see it in the queue, although I noticed there is “source amd64” in the 
Arch column, whereas Go libs seem to have “source all”. I’d like to make sure 
it’s available for any architectures Go supports. I see that dh-make-golang 
adds "Architecture: any” to debian/control for programs, and it adds 
“Architecture: all” for libraries. Is there something more I need to do?

Thanks,
Pete

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

[Pete Heist]

> On Feb 14, 2018, at 3:05 PM, Michael Stapelberg  wrote:
> 
> There’s nothing you need to do. I built it on amd64, as is currently still 
> required when uploading to the NEW queue (I would have preferred to upload 
> source-only). Once it’s accepted, the buildds will build it for all 
> architectures.

Great, thanks…

Pete

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

[Pete Heist]

> On Feb 9, 2018, at 11:43 AM, Pete Heist <p...@eventide.io> wrote:
> 
>> On Feb 9, 2018, at 8:15 AM, Michael Stapelberg <stapelb...@debian.org 
>> <mailto:stapelb...@debian.org>> wrote:
>> 
>> On Fri, Feb 9, 2018 at 2:09 AM, Pete Heist <p...@eventide.io 
>> <mailto:p...@eventide.io>> wrote:
>> 
>> From the original warnings you sent I know I’ve fixed all except "I: irtt 
>> source: testsuite-autopkgtest-missing”, but a) I’m not seeing that warning 
>> and b) I’m seeing two others. So my questions are:
>> 
>> 1) What are your expectations for 'testsuite-autopkgtest-missing', and why 
>> am I not seeing it? There are no unit tests to run.
>> 
>> Did you apply the ~/.lintianrc I provided? Not doing so would explain the 
>> difference. autopkgtest is helpful even if it only compiles the package in 
>> question. Why are there no unit tests for your code? :)
> 
>> 2) Do you care about 'debian-watch-does-not-check-gpg-signature' and 
>> 'no-upstream-changelog’? I do not sign the upstream, and the changes are in 
>> README.md, in case those should be split out...
>> 
>> They’re not important for the time being. Of course, if you could start 
>> signing upstream and provide a separate changelog file, that would be great.
>> 
>> Thanks!

Ok, I’ve updated the irtt package:

- I added a couple high-value unit tests, which also satisfies lintian.

- CHANGES.md is split out from README.md to satisfy 'no-upstream-changelog'.

- I tried getting signatures working but punted because GitHub creates a 
.tar.gz, which I signed with a .tar.gz.asc, but the build process expects a 
.tar.xz.asc in the upstream, so lintian then warns with 
'orig-tarball-missing-upstream-signature'. Is there any pkg-go example of 
signatures working with a GitHub hosted repo? Otherwise I’ll eventually figure 
it out.

- I blew away the irtt.git repo and started over so I could just stay on the 
rails of your dh-make-golang.html blog entry, hope that’s fine.

Let me know if anything else. Thanks!

Pete

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

[Pete Heist]

> On Feb 7, 2018, at 10:03 AM, Michael Stapelberg  wrote:
> 
> Thanks for contributing this package.

Not at all, thank you kindly for patience with my complete newness to this!

> The resulting binary package irtt_0.9-1_amd64.deb contains both a binary and 
> Go source code. This is a bit unusual: in Debian, we only package Go source 
> code to build other Go programs (not for developers). Hence, we usually 
> provide either a binary package with programs or an arch:all package with Go 
> source. It’s fine to have a source package which provides both, but please 
> separate the source from the binaries. Have a look at 
> https://anonscm.debian.org/cgit/collab-maint/codesearch.git/ 
>  for an example 
> of this pattern.

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? 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?

> Further, please address the following lintian warnings:
> 
> P: irtt source: package-uses-old-debhelper-compat-version 10
> P: irtt source: insecure-copyright-format-uri 
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ 
> 
> I: irtt source: out-of-date-standards-version 3.9.8 (released 2016-04-06) 
> (current is 4.1.3)
> I: irtt source: testsuite-autopkgtest-missing
> W: irtt: priority-extra-is-replaced-by-priority-optional
> 
> You can run lintian like so:
> % cat >> ~/.lintianrc <<'EOT'
> display-info = yes
> display-experimental = yes
> pedantic = yes
> show-overrides = no
> color = auto
> EOT
> % lintian irtt_0.9-1_amd64.changes

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
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?

> Let me know once this is done and I’ll be happy to take another look.
> 
> BTW, you don’t need to upload the package to mentors. I always work with the 
> git repository directly.

Ok, that makes sense to me also- received that tip from a different Debian 
package admin. Thanks! :)

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

[Pete Heist]

> On 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.

Ok, I’m getting there, bear with me. :) In my case, would I not want to produce 
both a binary package and eventually a source package?

> 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.
> 
> 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).

Got it...

> 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.

That explains a lot. I’ve got my work cut out for me on this part.

Thank you kindly…